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

Adrien de Croy wrote:
> Why would it though?   there's no actual need to close here.  Just 
> simply not send the request body,
> rather than closing, and pop up an auth dialog box.  It makes no sense 
> to waste resource by sending
> something the client KNOWS will be dumped.  The Greens will be after us !

The connection has to be closed because the proxy cannot tell if the
client received "102 wait" in time*, so the proxy cannot tell if the
next request is really another request, or a body which looks
identical to a request.

* You cannot assume that the round trip from client to proxy is small,
and you cannot assume that it's consistent from one request to
another.  There might be surprise network delays, there might be
scheduling issues at the client or the proxy, and also HTTP must work
over slow networks as well as fast ones.

> clients I've seen are really good at keeping the connection to a proxy 
> open, even when connecting to
> multiple different sites requiring different auth.
> 
> >
> >>5 client establishes auth credentials with proxy, still not sending 
> >>request body6 proxy connects to upstream server. 
> >>7. server sends 100 continue
> >>8 proxy sends server response back through to client
> >>9 client sends request body
> >>10 proxy relays request body.
> >>11. server sends 200 ok.
> >>12. proxy relays 200 ok.
> >>13 done.
> >>
> >>case 2, proxy requires auth, and server also requires auth.
> >>
> >>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"
> >
> >* client closes the connection to avoid transmitting the request body.
> >
> >>5 client establishes auth credentials with proxy, still not sending 
> >>request body
> >>6 proxy connects to upstream server. 
> >>7. server sends 401 auth required
> >>8 proxy sends server response back through to client
> >>9 client resends request with server credentials  Still no request body
> >>10 proxy relays request to server
> >>11. server sends 100 continue
> >>12. proxy relays 100 continue
> >>13. client sends request body
> >>14 proxy relays request body
> >>15 server sends 200 ok
> >>16 proxy relays 200 ok.
> >>17 done.
> >>
> >>case 3, only server requires auth
> >>
> >>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 connects to upstream server. 
> >>5. server sends 401 auth required
> >>6 proxy sends server response back through to client
> >>7 client resends request with server credentials  Still no request body
> >>8 proxy relays request to server
> >>9. server sends 100 continue
> >>10. proxy relays 100 continue
> >>11. client sends request body
> >>12 proxy relays request body
> >>13 server sends 200 ok
> >>14 proxy relays 200 ok.
> >>15 done.
> >
> >
> >case 4, server does not implement 100 Continue
> >
> >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 connects to upstream server. 
> >5. server sends 401 auth required
> >6. proxy sends server response back through to client
> >7*. client closes the connection to avoid transmitting the request body
> >8. client resends request headers with server credentials
> >8. proxy relays request headers to server
> >9. server doesn't implement 100 Continue and none gets sent..
> 
> If it's a new connection from step 8, then it's a new session.
> 
> if the client closes at step 7 above then it continues as
> 
> 0. client makes new connection to proxy
> 1. Client sends request headers only including server credentials 
> 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 connects to upstream server. 
> 5. proxy sends client request including credentials to server (presumably 
> the credentials are valid)
> 6. proxy waits for 100 continue from server.  If it doesn't receive one 
> within some time, it sends 100 continue to client.
> if it does get one from the server within that time, it sends it on to the 
> client.
> 7. client sends request body.
> 8. proxy relays request body
> 9. server sends 200 OK
> 10 proxy relays server response
> 11 done.
> 
> clients that support NTLM don't close when they get a 401 or 407, but I 
> guess they may if they haven't
> sent a request body.  Part of this support in the client for a wait 
> response would be changes to ensure
> that the client did not close the connection, since that's no longer 
> necessary, and breaks connection-based auth

The problem is that the client must send the request body (though it
could be chunked), or close the connection.  Anything else results in
an ambiguous data stream at the proxy, because the start of a request
is (in general) not distinguishable from the start of a request body.

Omitting the request body while continuing to use the connection is
only possible when the proxy is _certain_ the client is not sending
any request body.  But your scheme doesn't guarantee that, because (a)
the "102 wait" message might not be delivered fast enough to stop
transmission of the request body, and (b) the client might not support
it anyway (although a request header could indicate this support).

For this to work without the message parsing ambiguity, the client
would have to indicate, in a request header, that it will not send a
request body unless "100 continue" is recieved, with no timer.  But
such a client wouldn't work well with other servers.

> >For the connection to remain open without redefining the HTTP message
> >format or use chunked the request body MUST be transmitted and
> >discarded.
> 
> I guess more changes to the spec would need to be made to allow for the 
> request to be deemed complete
> without having to send the request body.
> 
> So, yes, it then is a change to the semantics of client requests.

A change would be needed which is interoperable with existing clients
and existing servers/proxies.  Unfortunately that's rather difficult.

> It looks like I omitted some things from the spec.  But, since the spec 
> would require changes
> to HTTP, and clients and servers and proxies, then is it too much of a 
> divergence to allow for
> the spec to also then cover a relaxation in strict cases (clearly 
> indicated) of the definition of completeness
> of a request?

The completeness is required so that clients interoperate with
existing proxies and servers, and vice versa.

> If we are going to change the protocol, and change clients, then we
> may as well change them to provide the best solution, not one that
> has known problems, simply to fall within the current letter of the
> current HTTP spec which we would be changing anyway.  There should
> be no ambiguities where a client supporting this encounters proxies
> and servers that dont either, so in all cases, the step to take
> should be clear.

I think there are several ambiguities which make your change
incompatible with existing proxies and clients.

   1. A client supporting this with an old proxy will work fine.

   2. A proxy supporting this with an old client will not work: it
      will send "102 wait", but it will receive a request body anyway.
      How can it tell it's receiving a request body, and not the start
      of another request?  After the request headers, a proxy cannot
      tell if the next data is the start of the next request, or the
      start of the request body.  They are indistinguishable (a body
      can legimitably begin with "GET /foo HTTP/1.1...").

   3. A client supporting this which does not receive "102 wait"
      quickly enough will still timeout and send at least part of the
      request body.  Causing the same problem as 2.

      This occurs when both client and proxy implement your spec!

   4. To fix 3, you could say a client will wait until it receives a
      1xx message before sending a request body, with no timeout.
      (Then you wouldn't bother with "102 wait".)  But this would then
      break 1, compatibility with existing proxies/servers which don't
      send 1xx.

I think the main problem with your proposal is the assumption that a
proxy can detect the difference between a request body, and the
start of another request with no intervening body.  But it
can't, because a body can look identical to a request.

And the other problem is that "102 wait" will be received by the
client quickly enough to stop it sending any request body; this cannot
be assumed.

-- Jamie

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