W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: SSL Tunneling; Informational RFC; Last call?

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Wed, 17 Sep 1997 00:52:41 -0700
To: Ari Luotonen <luotonen@netscape.com>
Cc: http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9709170103.aa11877@paris.ics.uci.edu>
Hi Ari,

>   This document specifies an Internet standards track protocol for the

This seems to be a misunderstanding in the draft.  If the RFC is to be
Informational, then it is not an Internet standards track protocol.

>   This document describes a way to do SSL tunneling without an
>   implementation of SSL, in a way that is compatible with the current
>   WWW proxy protocol (as defined by the HTTP/1.0 specification). The

That is out of date. Unless you are describing historical practice, all
references should be to HTTP/1.1, or HTTP/1.x.

>3. The CONNECT Method
>
>   The client connects to the proxy, and uses the CONNECT method to
>   specify the hostname and the port number to connect to. The hostname
>   and port number are separated by a colon, and both of them must be
>   specified.
>
>   The host:port part is followed by a space and a string specifying the
>   HTTP version number, e.g. HTTP/1.0, and the line terminator (CR LF
>   pair, or a single LF).
>
>   After that there is a series of zero or more of HTTP request header
>   lines, followed by an empty line. Each of those header lines is also
>   terminated by the CR LF pair, or a single LF. The empty line is
>   simply another CR LF pair, or another LF.
>
>   After the empty line, if the handshake to establish the connection
>   was successful, SSL data transfer can begin.
>
>   Example:
>
>         CONNECT home.netscape.com:443 HTTP/1.0
>         User-agent: Mozilla/4.0
>
>         ...SSL data...

Please note that the only reason this is a valid HTTP/1.x request, as
defined by RFC 1945 and 2068, is because "home.netscape.com:443" fits
within the syntax of an absoluteURI.  We should probably loosen that
requirement in the HTTP/1.1 revision.

Also, the above request is terminated by the empty line (which must
always be CRLF, BTW), so the "...SSL data..." should not be considered
part of the request.  That clearly isn't what you intended, but the
example makes it look like part of the request.  Perhaps if you
interleaved the client's requests with the server's response,
left and right justified respectively, the example would be clearer.

>   [HTTP/1.1] R. Fiedling et al, "Hypertext Transfer Protocol --
>              HTTP/1.1", RFC 2068, January 1997.

Ummm, my name is misspelled.  In any case, I prefer listing all the authors
and citing both RFCs for an Informational document:

   [HTTP/1.0] T. Berners-Lee, R. Fielding, and H. Frystyk.
              Hypertext Transfer Protocol -- HTTP/1.0.
              RFC 1945, MIT/LCS, UC Irvine, May 1996.

   [HTTP/1.1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
              T. Berners-Lee.  Hypertext Transfer Protocol -- HTTP/1.1.
              RFC 2068, UC Irvine, DEC, MIT/LCS, January, 1997.

....Roy
Received on Wednesday, 17 September 1997 01:16:44 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:01 EDT