This means that the proxy server cannot assume that reading from the
   client socket descriptor would only return the proxy request.
   Rather, there may be any amount of opaque data following the proxy
   request that must be forwarded to the server once the connection is
   established.  However, if the connection to the remote server fails,
   or if it is disallowed by the proxy server, the data intended to the
   remote server will be discarded by the proxy.

   At the same time this means that a client pipelining data intended
   for the remote server immediately after sending the proxy request (or
   in the same packet), must be prepared to re-issue the request and
   re-compose any data that it had already sent, in case the proxy fails
   the request, or challenges the client for authentication credentials.
   This is due to the fact that HTTP by its nature may require the
   request to be re-issued, accompanied by authentication credentials or
   other data that was either missing or invalid in the original
   request.

   Note that it is not recommended to pipeline more data than the amount
   that can fit to the remainder of the TCP packet that the proxy
   request is in.  Pipelining more data can cause a TCP reset if the
   proxy fails or challenges the request, and subsequently closes the
   connection before all pipelined TCP packets are received by the proxy
   server host.  A TCP reset will cause the proxy server's response to
   be discarded, and not be available to the client -- thus being unable
   to determine whether the failure was due to a network error, access
   control, or an authentication challenge.




 
TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT   August 1998


4. Extensibility

   The tunneling handshake is freely extensible using the HTTP/1.x
   headers; as an example, to enforce authentication for the proxy the
   proxy will simply use the 407 status code and the Proxy-authenticate
   response header (as defined by the HTTP/1.x specification) to ask the
   client to send authentication information:

         HTTP/1.0 407 Proxy authentication required
         Proxy-authenticate: ...


   The client would then reperform the request, and send the
   authentication information in the Proxy-authorization header:

         CONNECT home.netscape.com:443 HTTP/1.0
         User-agent: ...
         Proxy-authorization: ...

         ...data to be tunnelled to the server...


   The full example displayed in an interleaved multicolumn format:

     CLIENT -> SERVER                        SERVER -> CLIENT
     --------------------------------------  -----------------------------------
     CONNECT home.netscape.com:443 HTTP/1.0
     User-agent: Mozilla/4.0
     <<< empty line >>>
                                             HTTP/1.0 407 Proxy auth required
                                             Proxy-agent: Netscape-Proxy/1.1
                                             Proxy-authenticate: ...
                                             <<< empty line >>>
     CONNECT home.netscape.com:443 HTTP/1.0
     User-agent: Mozilla/4.0
     Proxy-authorization: ...
     <<< empty line >>>
                                             HTTP/1.0 200 Connection established
                                             Proxy-agent: Netscape-Proxy/1.1
                                             <<< empty line >>>
                  <<< data tunneling to both directions begins >>>


5. Multiple Proxy Servers

   This specification applies equally to proxy servers talking to other
   proxy servers.  As an example, double firewalls make this necessary.
   In this case, the inner proxy is simply considered a client with




 
TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT   August 1998


   respect to the outer proxy.


6. Security Considerations

   The CONNECT tunneling mechanism is really a lower-level function than
   the rest of the HTTP methods, kind of an escape mechanism for saying
   that the proxy should not interfere with the transaction, but merely