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" <>
> Date: Thu Apr 11, 2002  11:51:15  AM US/Pacific
> To: "'Michael Brennan'" <>, <>
> Cc: "Keith Moore" <>
> Subject: RE: [HTTPSubstrate-16] What is W3C's position on RFC 3205?
> Reply-To: <>
>> I have also run afoul of faulty HTTP client stacks that don't respect 
>> 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
> --
Mark Nottingham

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