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

tis 2007-02-13 klockan 12:58 +1300 skrev Adrien de Croy:

> then the problem can still be clearly shown.
> 
> 1. Client wants to post to server.
> 2. client connects to proxy, sends initial request, but not body
> 3. client waits for 100 continue.
> 4. proxy evaluates request, DNS and policy lookups etc. some time elapses.
> 5. Proxy Initiates connection to sever.. some more time elapses.
> 6. Client stops waiting for 100 continue and starts sending body
> 7. proxy achieves connection, server sends 401 auth required
> 8. proxy passes back 401 auth required
> 9. client has to terminate connection and start again.

Well.. no matter what the client only has the choice of either closing
the connection or sending the request body. That's the only two
available options once the request headers have been sent indicating
there will be a request entity body.

Adding a new "Defer" status code does not change this, and is why I got
confused by your draft into thinking that you somehow proposed that the
client should change how it sends the request body.

> At least with basic auth, the credentials can be submitted the second time.

Yes. And the same for Digest or any other message based authentication
scheme following the HTTP/1.1 protocol requirements.

> If the intermediary is an intercepting proxy however, and requires auth 
> (even basic)
> then breaking the connection will lose the auth either to the server or 
> proxy,
> since there can't be 2 sets of Authorization tags, and so this situation 
> prevents
> operation completely unless the client sends chunked data as you've 
> suggested.

An intercepting proxy can not use HTTP auth as HTTP proxy auth is only
possible when following specifications.

Not a all. It's just that if any hop uses NTLM or other connection
oriented aurh sceme then closing the connection is not an option so the
request body MUST be transmitted in order for the authentication to
work.

The new "defer" status code only avoids situations where the body is
unneededly transmitted before closing the connection. It does not at all
solve the problems of NTLM or other connection oriented authentication
methods.

> I am thinking more about your point about using TCP flow control.  We 
> are able to
> send a 0 window size, but that won't guarantee that the client won't 
> enter into the
> state where it thinks it is sending the body (and would therefore 
> terminate on
> any 4xx response).

Terminating the connection on 4xx is completely unrelated to if the
client has begun sending the request body or not. That's a property of
the server response and the preferences of the client just as any other
request/response pair.

The only way of not having to send the complete request body without
closing the connection is to use chunked encoding. If Content-Length is
used then the client MUST either send the indicated amount of data or
close the connection no matter what response is received.

Regards
Henrik