- From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Date: Sun, 10 Aug 1997 16:49:21 -0500 (EST)
- To: kweide@tezcat.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Klaus Weide <kweide@tezcat.com> wrote: >On Sat, 9 Aug 1997, Roy T. Fielding wrote: >>[...] >> That simply isn't true unless you have changed the proxy recently. >> 1.0 required that the proxy send it's own version in any forwarded >> request or response. The CERN, Netscape, and Apache proxies all obeyed >> that restriction last time they were checked. If Squid managed to scew >> that up even after three RFCs have been published on the subject, then >> they can't be trusted to have implemented anything right. > >A quick check with reality. localhost:8080 is CERN/3.0, localhost:squid >is Squid 1.1.1, none of them "changed recently". >[...] >This shows that at least these two 1.0 proxies do not send their own >version in a forwarded (OR cached) RESPONSE. > >Now for whether they downgrade the version to their own in a REQUEST - >yes, they both do: (only shown for CERN/3.0) >[...] >So both proxies act according to the expectation (aka: requirement) in one >direction but not in the other. > >A HTTP 1.0 client accessing a 1.1 origin server through such a proxy >will never improperly receive (for example) a chunked response, since the >server won't send it through that proxy. > >The only harm I can see is with a HTTP 1.1 (or higher) client, which could >be misled into believing that it is talking to a 1.1 proxy. As a result >it might attempt to use a 1.1-only feature in a later request through that >proxy - for example sending a chunked request body in a POST. > >[... suggested protocol mod ...] > >This is one idea that would require cooperation (or a protocol change) from >servers not directly involved. However, since the problem is only with >detecting the correct version of a next-hop proxy, there often will be >other means - out-of-band information or configuration, checking directly >with OPTIONS or TRACE if a proxy appears to be >1.0, or similar. 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). Fote ========================================================================= Foteos Macrides Worcester Foundation for Biomedical Research MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545 =========================================================================
Received on Sunday, 10 August 1997 13:52:15 UTC