Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

Henrik Nordstrom wrote:
> tis 2007-02-13 klockan 08:51 +1300 skrev Adrien de Croy:
>   
> a) There is no guarantee the client will actually wait for the 100
> Continue response before sending the request body, especially not when
> there is intermediaries involved which may significantly delay the
> request or response, so the server may get a response body even after
> sending the "abort" signal and this may then get misread as a different
> request (i.e. a PUT of a object containing an HTTP request).
>
>   
sorry, I just re-read this.  I presume you mean a server/proxy may get a
request body after sending a 1xx defer
before sending a 100 continue.  In this case, it's a fairly unambiguous
indication that the client doesn't support this
spec, and the proxy/server should continue as per the current situation.

If a proxy or server sends a 1xx defer to a client, there are several
things that may possibly happen:

1. the client doesn't recognise it and fails in some way (e.g closes the
connection or goes into a spin).  This doesn't comply with section 10.1
of RFC2616.
2. the client ignores it
3. the client treats it as a green light and sends the content immediately
4. the client understands it, and waits for a 100 continue.

each of these should be unambiguous for the server.  Actually para 3 of
RFC2616 10.1 implies that 100 continue and Expects: 100-continue are
hop-by-hop negotiation.

Maybe a status code isn't the best way to achieve flow control, and it
could/should be done with Connection tags?  But in the end if you want
to actively stop a client from sending the body (presuming this is
deemed desirable), then some sort of  message needs to be actively sent
to the client.

for example, a Client which understands flow-control semantics could
send a request such as (just plucking tag-names out of thin air here)

POST http://www.wingate.com/testform.php HTTP/1.1
Host: www.wingate.com
Connection: Keep-alive; Flow-Control=on
Content-Length: 512
Progress: 1 en-nz
etc

then any provisional response except for 100 continue (which is a green
light which is undesired in this case) could send a Connection tag back e.g.

HTTP/1.1 102 Processing
Connection: Flow-Control=Wait; Keep-alive
Progress: %0; Connecting to upstream server
etc

then

HTTP/1.1 100 Continue
Connection: Flow-Control=Proceed; Keep-alive
Progress: %0; Connected to upstream server

this at least allows a client to advertise support for flow-control
without jeopardising the request (as it would be with an Expects
header).  It also allows servers / Proxies to deal with it even if they
don't understand it.

Other problems with the chunked approach.

1. the proxy doesn't know if it has received the whole resource or not,
and what should it do with it.  It may already have started passing it
up to the server.  If the server is HTTP/1.0, then the proxy will have
to be able to handle a rejection of the initial request, and in that
case send unchunked data.

Makes life difficult for proxy vendors, which I why I'm here.  We
already get complaints about file uploads with auth etc.  It would be
nice to actually solve our customers' problems in that regard, and this
should benefit all web users, not just ours.

In the end though, we are supporting chunked data from a client with our
next major version (although we will need to write a client to test
it!), and should be able to resynch this scenario.  I really can't vouch
for anyone else though.

Cheers

Adrien

Received on Tuesday, 13 February 2007 07:44:10 UTC