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

Re: SSL Tunneling; Informational RFC; Last call?

From: <rlgray@raleigh.ibm.com>
Date: Tue, 16 Sep 1997 12:42:26 EST
Message-Id: <199709161642.MAA26452@rtpmail02.raleigh.ibm.com>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4429
Forwarding note from: Martin Presler-Marshall <mpresler@us.ibm.com> Tue, 16 Sep 1997 11:24:06 -0400

 There is, I hope, one bug in this draft. In section 6, an example is given of
a non-200 return code (specifically, a 407) from the proxy. After the plaintext
HTTP header, the draft says that "...SSL data..." will be sent. This violates
the requirement that the proxy need not have a complete SSL implementation. The
proxy server, assuming that it doesn't actually understand SSL - or whatever
protocol is being tunneled - can only sent back a standard HTTP/1.0 or HTTP/1.1
response. Therefore, the 407 response (or any other error response) should send
back a content-type in its headers, and the appropriate type of response -
unencrypted - in its content-body.

 This then begs the question of whether the "200 OK" response to a CONNECT
request should include a content-type (our tunneling implementation does not
currently send one). I think that it should, and a new MIME type like
"application/tunnel" should be sent. This is obviously not a requirement, but
would be nice for completeness.

 -- Martin

Richard L. Gray
chocolate - the One True food group

cc: luotonen@netscape.com
Received on Tuesday, 16 September 1997 09:45:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC