RE: ISSUE: MUST a client wait for 100 when doing PUT or POST re quests?

David W. Morris writes:
 > This really dicates that a proxy establish a thru path between its
 > server side connection to the client and its client side connection to
 > the down stream server. My unimplemented as of now design is more oriented
 > to being able to treat requests as autonomous things which are bundled up
 > and handed off to server connections and then re-assembled in the correct
 > order to return responses to the client.

Jigsaw conforms to your design requirement (the proxy client side is
totally independant of the proxy server side), while still conforming
to the 100 status code rule. It's a real problem to implement (not the
only one ;-), but I think it's worth it (it does even send a fake 100
status code to a 1.1 client if the origin server is 1.0)

 > A quick re-read of pieces of the RFC would lead me to the conclusion that
 > it is quite permissable for the PROXYSERVER to send an immediate
 > 100 CONTINUE, gather the whole request and pass it on the the 
 > next server toward the origin.

The implementation of the client side allows for events to be sent as
the request gets processed. The server side of the proxy registers to
these events, one of them is the reception of a 100 status code. When
the server side gets that event it sends back the 100 to the
client. If the server side doesn't get that event before getting the
reply, it fakes one before emitting the reply from the server.
[in a browser these events could be used to display the usual
'connected' etc messages in a status bar]

Jigsaw source code is available at http://www.w3.org/Jigsaw

Hope this helps,
Anselm.

Received on Wednesday, 11 June 1997 00:56:31 UTC