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

Jamie Lokier wrote:
> Adrien de Croy wrote:
>   
>> case 1, proxy requires auth, server does not.
>>
>> 1. Client sends request headers only (as per current RFC2616 
>> suggestions) and goes into a short wait state
>> 2. proxy sees that there will be a request body, so immediately sends 
>> "HTTP/1.1 1xx wait please"
>> 3. client terminates timer for when it would otherwise send request 
>> body.  It does not send request body
>> 4 proxy then sends "HTTP/1.1 407 auth required"
>> 5 client establishes auth credentials with proxy, still not sending 
>> request body6 proxy connects to upstream server. 
>>     
>
> But, if I've understood that, it does not work.
>
> This is what I think happens in your scheme:
>
>  1. Client sends request headers only.
>  2. Proxy sends "HTTP/1.1 1xx wait please".
>  3. Client receives "HTTP/1.1 1xx wait please" and does not send request body.
>  4. Some time later, proxy sends "HTTP/1.1 407 auth requiered"
>  5. Client sends new request headers to establish auth credentials...
>
> But there is a problem.  What happens if the "HTTP/1.1 1xx wait
> please" is not received quickly enough by the client?  Current clients
> will time out and send the request body:
>
>  1. Client sends request headers only.
>  2. Proxy sends "HTTP/1.1 1xx wait please", but this takes a few
>     seconds to transit the network due to delays.
>  3. Client's "100 continue" timer times out, and it begins sending the
>     request body.
>  4. Some time later, client receives "HTTP/1.1 1xx wait please".
>
> The problem is, how shall the proxy parse the data stream from the
> client?  In the first case, the data stream consists of request
> headers indicating a request body, but no body, followed by more
> request headers.  In the second case, the data stream consists of
> request headers indicating a request body and at least part of a
> request body.
>
> How can the proxy detect the start of the second request in each case?
> It's not possible to distinguish request headers from the start of a
> request body.
>   
hmm, good point.  There is a very small chance that the request body 
could look like a normal request.

Normal scenario is proxy on same LAN as client, so delays would be very 
small.  If the proxy is
across the internet, then delay would be in line with RTT to connect to 
the proxy.  But still it's always
better to have a completely deterministic method - with no room for 
guessing.

The problem you raise is easily fixed though, if we require the client 
to advertise support for flow control
with a tag in say the Connect header (or maybe another tag).

In that case, the proxy only sends the 102 if the client advertised 
support for it.  I wouldn't suggest using
the expects header, since the proxy or server would then be required to 
reject the request if it didn't understand
rather than just ignore the tag (no graceful fall-back).  The 
advertisement could also contain info about how
long the client will wait before sending the message body if there is no 
100 continue or 102 please wait.

It needs to be an advertisement that is safe to send to any server 
without causing a rejection.

> This is the reason why a client is only allowed to send a request
> body, or abort the connection.  And this is why it is said the only
> solutions are to use chunked request body (which is always sent, but
> can be truncated), or for the client to send a request header which
> means "I will definitely not send a request body unless I receive 100
> Continue".  But both of those will fail with some servers and some proxies.
>   
yes, I think the expects header has some resistance to implementation.  
Due mainly to

1. difficulty in clients maintaining knowledge about whether servers 
support 100 continue or not
2. possibility that any request sent with a expects header will be 
rejected purely because of that header.
3. lack of support from HTTP/1.0 servers

If all the web clients I've investigated this for actually used an 
Expects header, this would be a moot point
but I've never seen one sent... ever.

Maybe the IE and Firefox teams are just a bit paranoid :)

>   
>> I should really draw up a flow chart of all this.  from the client's 
>> point of view, it sends a request, and if it receives a 102
>> wait please, it will then receive any number of:
>>
>> a. a 100 continue
>> b. an auth challenge
>> c. some failure code indicating the request is denied.
>> d. connection closed (some failure condition)..
>>
>> until it has received a 100 continue however, it won't send the request 
>> body.
>>     
>
> But what about the case when "102 wait please" is sent by the proxy or
> server, but isn't received by the client fast enough to make it wait?
>
> -- Jamie
>

Received on Wednesday, 14 February 2007 16:06:58 UTC