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

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.

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.

> 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 15:51:49 UTC