W3C home > Mailing lists > Public > www-tag@w3.org > April 2002

RE: [HTTPSubstrate-16] What is W3C's position on RFC 3205?

From: Larry Masinter <LMM@acm.org>
Date: Thu, 11 Apr 2002 11:51:15 -0700
To: "'Michael Brennan'" <Michael_Brennan@Allegis.com>, <www-tag@w3.org>
Cc: "Keith Moore" <moore@cs.utk.edu>
Message-ID: <00a701c1e189$dba46dc0$3a432099@larrypad>
> I have also run afoul of faulty HTTP client stacks that don't respect HTTP
> semantics in my programming -- including the HTTP client included in the
> W3C-sponsored Jigsaw project. Last time I checked (admittedly over a year
> ago), it included code that would intercept HTTP error status codes from
> proxy servers, and return to the client an HTTP status code of 200 and a
> generic HTML message with a generic error message (while blocking the
> message body from the server).

I question your use of "faulty"...

> Trying to steer standards around such abuses is not a promising path
> forward, in my opinion. The TAG and/or IETF really should issue a best
> practices document admonishing such behavior and exhorting implentors to
> respect HTTP semantics.

Well, for better or worse, RFC 2616 reflects, in several places,
an acknowledgement that there are translating proxies that do
a wide variety of content transformations of results. For example,
there would be no need for a "no-transform" directive if it weren't
for that acknowledgement (RFC 2616 section 14.9.5).

I'm not sure where to get "HTTP semantics" from, except from the
document that defines HTTP. There may be some difficulties with
having intermediaries transform data without warning, but the
design of HTTP for web browsing allowed for these kinds of modifications.

The HTTP specification distinguishes semantically transparent
caches from other kinds of intermediaries, but it doesn't declare
non-transparent intermediaries to be an "abuse". The introduction
in Section 13 of RFC 2616 is very explicit about the conditions
in which transparency may be relaxed, in the section starting:

"The HTTP/1.1 protocol allows origin servers, caches,
 and clients to explicitly reduce transparency when necessary."

Since this is the actual definition of HTTP, you could say,
on the contrary, that it is an "abuse" of HTTP to design
protocols in general (and the XML Protocol binding to HTTP in
particular) in a way that ignores this possibility or assumes
that it doesn't happen.

Received on Thursday, 11 April 2002 14:53:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:31 UTC