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

Re: RE-VERSION

From: Klaus Weide <kweide@tezcat.com>
Date: Sun, 10 Aug 1997 17:36:49 -0500 (CDT)
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970810171937.27651G-100000@xochi.tezcat.com>
On Sun, 10 Aug 1997, Foteos Macrides wrote:

> 	In an earlier round of discussions about this, when that false
> claim was checked against reality, and the consequent problem of it
> leading to inappropriately chunked POSTs was raised, the suggested
> workaround kludge was your second, i.e., for the client to send an
> OPTIONS request, and proceed with the chunked POST only if it doesn't
> get back a 400 from the broken proxy.  That'll work with the CERN proxy,
> but I don't know about Squid, or if any other proxies are similarly broken
> in reality (from Josh's original message, it seems likely the Netscape
> proxy also passes through the origin server's status line for the response,
> without changing the minor version number to it's own).

Well, it (Squid 1.1.1) doesn't give a 400 response, but the response
definitely makes clear that this is no HTTP 1.1 server :)
Actually any response to OPTIONS which does not start with a valid
"HTTP/1.1" (or higher) Status-Line should be enough to discredit a
proxy's previous response with such a version.

       Klaus

$ telnet localhost squid
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS / HTTP/1.1
HTTP/1.0 0 Cache Detected Error
Content-type: text/html

<HTML><HEAD><TITLE>ERROR: Invalid HTTP Request</TITLE></HEAD>
[ some more lines of HTML snipped ]
Received on Sunday, 10 August 1997 15:37:44 EDT

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