RE: Is 100-Continue hop-by-hop?

Are proxies not already prevented from safely multiplexing streams
because of cookies, authentication, and OPS?

If client A sends up a cookie to http://foo and client B sends up a
cookie to http://foo there is no way, just looking at the response, to
know which of the two responses the server generates is meant for which
client. 

A similar situation applies to authentication where client A and client
B may both perform a GET on a resource with authentication information
and one client makes it and the other doesn't, given that custom
authentication mechanisms can be used, there is no way for the proxy to
figure out which response was intended for which client.

A similar situation also applies to OPS. Two clients may establish an
OPS session with a server and then make separate requests for the same
resource. The response may be different based upon the OPS information
but there is no way to examine the response and know which client that
particular response is meant for.

Of course, its late and maybe I missed something. But it looks to me
like proxy multiplexing is already impossible.

		Yaron


> -----Original Message-----
> From:	koen@win.tue.nl [SMTP:koen@win.tue.nl]
> Sent:	Thursday, July 10, 1997 1:16 PM
> To:	Yaron Goland
> Cc:	mogul@pa.dec.com; dwm@xpasc.com; http-wg@cuckoo.hpl.hp.com
> Subject:	Re: Is 100-Continue hop-by-hop?
> 
> Yaron Goland:
> >
> >On 100 being hop by hop, I would also throw in the following scenario
> >from DAV land:
> >A client executes a COPY on a container with a large number of
> members.
> >The user agent will want to be able to provide update information on
> how
> >the copy is progressing rather than just sitting there for a few
> minutes
> >while the procedure is underway. 100 continue responses are perfect
> for
> >this scenario.
> 
> Sorry, but 100 continue is _not_ perfect for this scenario.  There is
> a message by Jeff in the archives which explains why.  Basically, a
> proxy which is multiplexing requests from multiple clients over a
> single upstream connection would have no idea to which client a 100
> continue would have to be forwarded.
> 
> 1.1 does not offer an end-to-end event notification service, nor can
> 100 be easily `fixed' to produce such a service.  Adding such a
> service is out of scope for this WG I think.  IF DAV needs something,
> I suggest that you either document Netscape server push and use that,
> or spec a mechanism in which the client makes occasional status
> requests.
> 
> >		Yaron
> 
> Koen.

Received on Thursday, 10 July 1997 18:39:05 UTC