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


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>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4148
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.


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

[ some more lines of HTML snipped ]
Received on Sunday, 10 August 1997 15:37:44 UTC

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