Issue: HTTP transcoding [ was: What is W3C's position on RFC 3205? ]

Has the WG considered whether to give advice about/dictate handling of 
the 'no-transform' cache-control directive, as well as the '214 
Transformation applied' warning-value in the HTTP binding? It may be 
prudent to do so.


Begin forwarded message:

> From: "Larry Masinter" <LMM@acm.org>
> Date: Thu Apr 11, 2002  11:51:15  AM US/Pacific
> To: "'Michael Brennan'" <Michael_Brennan@Allegis.com>, <www-tag@w3.org>
> Cc: "Keith Moore" <moore@cs.utk.edu>
> Subject: RE: [HTTPSubstrate-16] What is W3C's position on RFC 3205?
> Reply-To: <LMM@acm.org>
>
>> 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.
>
> Larry
> --
> http://larry.masinter.net
>
>
>
>
>
>
--
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 11 April 2002 16:20:21 UTC