Re: HTTPbis -10 drafts published

Hi,

> <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#appendix-C.11>

This one is still rather vague about the CONNECT method (7.9).
It says :

   This specification reserves the method name CONNECT for use with a
   proxy that can dynamically switch to being a tunnel (e.g., SSL
   tunneling [RFC2817]).

It's still not easy to implement HTTP-compliant intermediaries based on
this, especially since the RFC above is cited as an example of usage,
and it does not seem very obvious to check for the TLS RFC to find the
semantics of an HTTP method.

There is also an important aspect to consider which are not specified
even in RFC2817 : what to do with the body if any is specified in the
request or in the response ? (I've seen some proxies return
"Content-length: 0" in response to a CONNECT, maybe they've encountered
issues with some old user-agents). While a proxy won't probably care, a
reverse-proxy based load balancer sitting in front of a proxy cares a bit
more. For instance, let's suppose the reverse proxy is forwarding a
request body advertised in the content-length header, as allowed by
httpbis-p1#3.3. Suddenly, the proxy responds with "200 established".
Should the reverse proxy silently consume the remaining data, should it
pass them to the proxy assuming they will be considered as part of the
tunnelled data ? Should it break the connection since after all it's the
client's fault ? When it happens in the response, it may cause the reverse
proxy to forward the response body until the advertised number of bytes is
reached, and only then the tunnel would be established. But the server
might be waiting for some upstream tunnelled data before sending more.

So shouldn't we simply state that both the request using a CONNECT method
and its response which indicates the tunnel is established MUST NOT
contain a body and that clients, intermediates and proxies MAY reject
such messages ?

Since TLS is not the only protocol using CONNECT anymore (even WebSocket
intends to use it), I suggest that we move the description from the
RFC2817 to httpbis-p2 :

  5.2 Requesting a Tunnel with CONNECT


   A CONNECT method requests that a proxy establish a tunnel connection
   on its behalf. The Request-URI portion of the Request-Line is always
   an 'authority' as defined by URI Generic Syntax [2], which is to say
   the host name and port number destination of the requested connection
   separated by a colon:

      CONNECT server.example.com:80 HTTP/1.1
      Host: server.example.com:80

   Other HTTP mechanisms can be used normally with the CONNECT method --
   except end-to-end protocol Upgrade requests, of course, since the
   tunnel must be established first.

   For example, proxy authentication might be used to establish the
   authority to create a tunnel:

      CONNECT server.example.com:80 HTTP/1.1
      Host: server.example.com:80
      Proxy-Authorization: basic aGVsbG86d29ybGQ=

   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
   sent immediately after the blank line. The usual caveats also apply:
   data may be discarded if the eventual response is negative, and the
   connection may be reset with no response if more than one TCP segment
   is outstanding.

  5.3 Establishing a Tunnel with CONNECT


   Any successful (2xx) response to a CONNECT request indicates that the
   proxy has established a connection to the requested host and port,
   and has switched to tunneling the current connection to that server
   connection.

   It may be the case that the proxy itself can only reach the requested
   origin server through another proxy.  In this case, the first proxy
   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
   to the authority.  A proxy MUST NOT respond with any 2xx status code
   unless it has either a direct or tunnel connection established to the
   authority.

   An origin server which receives a CONNECT request for itself MAY
   respond with a 2xx status code to indicate that a connection is
   established.

   If at any point either one of the peers gets disconnected, any
   outstanding data that came from that peer will be passed to the other
   one, and after that also the other connection will be terminated by
   the proxy. If there is outstanding data to that peer undelivered,
   that data will be discarded.

Any thoughts ?

Regards,
Willy

Received on Wednesday, 14 July 2010 06:51:07 UTC