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

Re: SSL Tunneling; Informational RFC; Last call?

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 16 Sep 1997 20:50:40 -0500 (EST)
To: masinter@parc.xerox.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01INQ1UVTU6A002NV1@SCI.WFBR.EDU>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4437
Larry Masinter <masinter@parc.xerox.com> wrote:
>> >  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.
>> I have nothing against a MIME type, but I think that this RFC should
>> document the current behavior, and currently there is no MIME type.
>Well, if the standard says that HTTP bodies must be labelled with
>a content-type, then you should point out that this is an exception,
>or recommend that it be sent but note that it isn't implemented.
>That is, the RFC can not only document current behavior, it can also
>propose changes to current behavior, if it's advisable.

	Assuming the Netscape proxies handle CONNECT requests like
CERN proxies with Ari's patch, they return:

	HTTP/major.minor 200 connection establishedCRLFCRLF

with no body.  A UA also receives a 200 with no body for a HEAD
request.  So it seems simply a matter of making clear in the RFC
that no body is returned with the 200 for a CONNECT request, and
the UA simply proceeds with its handshake, etc., through the tunnel.
It makes no sense for the proxy to return a Content-Type header on
success for that method.

	One might argue that the proxy should return a 204 (no content),
but the RFC descriptions for a 204 indictate that the UA should restore
the current document on receiving a 204, and that's not what the UA
should do on receiving a success status code for a CONNECT request.


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Tuesday, 16 September 1997 17:56:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC