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


From: Klaus Weide <kweide@tezcat.com>
Date: Sun, 10 Aug 1997 15:39:29 -0500 (CDT)
To: Scott Lawrence <lawrence@agranat.com>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.95.970810125526.27651C-100000@xochi.tezcat.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4142
On Sun, 10 Aug 1997, Scott Lawrence wrote:

>   Klaus Weide <kweide@tezcat.com> provides us with traces showing two
>   deployed proxy implementations that plainly do not send correct HTTP
>   version numbers on thier forwarded responses, and suggests a
>   modification to 1.1 to provide a way to detect this broken behaviour
>   so that correct implementations can work through it.
>   Those implementations are and always have been _broken_.  They
>   plainly do not conform to the specifications, and should be fixed
>   and replaced.

I question that "always have been" part.  Correct me if I am wrong but
AFAIK one of those implementations was written long before "the
specification".  One could just as well claim that RFC 1845 is broken,
since it failed in its claim to reflect "common usage" and to describe
"the features that seem to be consistently implemented".

>                  It is true that as 1.1 origin servers and especially
>   1.1 clients come into wider use, these broken 1.0 proxies will begin
>   to cause problems; the client users will generally be the ones to
>   suffer for it.  With IE4 preview versions being distributed I
>   expect that this is already happening.

They seem to be doing fine without help from old 1.0 proxies -
By the way, that workaround at first look (according to the included
description of the problem) seems to be a practical application of the
exemption in RFC 2145 2.3 last para:
  "An HTTP server MAY send a lower response version, if it is known or
   suspected that the client incorrectly implements the HTTP
   specification, but this should not be the default, and this SHOULD
   NOT be done if the request version is HTTP/1.1 or greater."
On second look, it seems that the desired "downgrading" effect for the
client in question could also be achieved by sending "Connection: close"
and not sending chunked entities, while still responding with "HTTP/1.1".

>   If I were implementing a 1.1 browser, I would spend a few minutes
>   adding an interface that used TRACE or OPTIONS to at least help
>   users discover what the problem really is, and I'd put up some help
>   pages about it (on 1.0 servers :-).  Then I'd add a link on the help
>   pages to my (correct) proxy product so that users could complain to
>   the adminstrator of the firewall or ISP whose broken proxy they are
>   stuck behind.  In short, view this as a sales opportunity.

That might not be such a good idea after all.  While you have been
busy to make your product apparently harder to use, your competitors
a, b, and c came up with the clever idea to auto-detect such a proxy 
(maybe with TRACE or OPTIONS or just 'HEAD /') and just treat it as 1.0.  
I think a, b, and c will look better than you.

>   These non-conforming proxies are no reason to do anything at all to
>   the definition of HTTP.

I am not saying they are a reason to change the meaning of versions
from that in the RFC.  (And the connection token idea was just that,
an idea.)  But if HTTP 1.1 aspires to be widely deployed and to
"support the wide diversity of [cache and proxy] configurations
already deployed" (RFC 2068 1.4), then it should at least offer some
advice how to deal with those old proxies, instead of insisting that
they first all have to go away before things can work.

Received on Sunday, 10 August 1997 13:41:14 UTC

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