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

> From: Larry Masinter [mailto:LMM@acm.org]
> Sent: Thursday, April 11, 2002 11:51 AM
> To: 'Michael Brennan'; www-tag@w3.org
> Cc: Keith Moore
> Subject: RE: [HTTPSubstrate-16] What is W3C's position on RFC 3205?
> 
> 
> > 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).

And the spec says that "no-transform" directive MUST be respected.

> 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.

Really? Then explain to me this (from section 13.5.2):

    A non-transparent proxy MAY modify or add these fields to a 
    message that does not include no-transform, but
    if it does so, it MUST add a Warning 214 (Transformation applied) 
    if one does not already appear in the message
    (see section 14.46).

How do you get "without warning" from that passage? Or this (from 14.9.5,
the same one you cite):

    Implementors of intermediate caches (proxies) have 
    found it useful to convert the media type of certain entity
    bodies. 
    ...
    Therefore, if a message includes the no-transform directive, 
    an intermediate cache or proxy MUST NOT
    change those headers that are listed in section 13.5.2 
    as being subject to the no-transform directive. This
    implies that the cache or proxy MUST NOT change any aspect 
    of the entity-body that is specified by these
    headers, including the value of the entity-body itself.

That seems to be pretty clear to me. I don't see how that sanctions
indiscrimate transformations "without warning". It seems to place pretty
clear constraints on such transformations.

Quite apart from that, the HTTP spec provides a pretty clear definition of
what a status code of 200 means. In section 10.2.1 it is defined to mean
"the request has succeeded". How does changing an HTTP error status to 200
(indicating success) meet the criteria of allowed transformations?

<snip/>

> 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.

That's a bizzarre statement. There is no problem, here, if the
intermediaries and toolkits abide by the HTTP spec. A client should be able
to rely upon the fact that a "no-transform" header will be respected. It
should be able to count on the fact that intermediaries (or programming
toolkits) are not transforming responses "without warning". And they should
be able to count on the fact that an HTTP status code of 200 means that
processing of the request was completed successfully, just as the HTTP spec
states. It is not "abuse" to expect HTTP implementations to abide by the
HTTP specification.

I won't debate this any further. There's no point, and it is just adding to
bandwidth. It seems to me, though, that HTTP should be defended, and not by
fixating purely on section 9.1.1.

Received on Thursday, 11 April 2002 18:19:37 UTC