W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 11 Apr 2002 16:47:07 -0700
Cc: xml-dist-app@w3.org, LMM@acm.org
To: Christopher Ferris <chris.ferris@sun.com>
Message-Id: <6F37086E-4DA6-11D6-B12D-000A27836A68@mnot.net>
That's specific to the case where SOAP intermediaries are colocated with 
HTTP intermediaries (perhaps even just proxies, not gateways); i.e, HTTP 
is doing the routing.

I was thinking more of the case where a SOAP message passes through an 
HTTP intermediary that does transcoding in some form. It seems like it 
would be a good idea to recommend sending no-transform in all SOAP 
messages bound to HTTP (request and response, although the situation 
above will need to be dealt with), so that these intermediaries won't 
process the message.

Another situation involves HTTP intermediaries that process SOAP 
messages without being explicitly targeted; they aren't SOAP nodes in 
the strict interpretation, but they may add blocks, etc. This may be 
legitimate in some cases.

I imagine that some text might be added to the draft highlighting 
no-transform, so that implementations can use it if they desire. It 
wouldn't be a good idea to mandate it, for the reasons outlined above 
(it could be a property; generally, people would want to use it unless 
they want to allow HTTP intermediaries to process the message without 
being targeted).

Regarding Warning, its presence in a HTTP-bound message (request or 
response) should be available to receiving implementations (perhaps as a 
property?), so that they can act accordingly. Also, it may help debug 
cases where the SOAP status doesn't match the HTTP status...



On Thursday, April 11, 2002, at 04:17  PM, Christopher Ferris wrote:

> Mark,
>
> Interesting observation. Seems to me though that the no-transform
> directive if applied with SOAP header blocks targetted at an role
> other than the ultimate recipient URI might present an unreconcilable
> conflict with an intermediary SOAP node that was acting in the
> role specified by that URI such that it could not perform its
> obligations w/r/t the SOAP process model.
>
> Just a thought,
>
> Chris
>
> Mark Nottingham wrote:
>
>> 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/
>
>
>
--
Mark Nottingham
http://www.mnot.net/
Received on Thursday, 11 April 2002 19:47:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT