W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2007

Tranfer-Encoding vs Content-Encoding

From: Philippe Le Hegaret <plh@w3.org>
Date: Tue, 16 Jan 2007 09:50:34 -0500
To: keith chapman <keithgchapman@gmail.com>
Cc: www-ws-desc <www-ws-desc@w3.org>
Message-Id: <1168959034.2988.13.camel@localhost>

I talked to Yves Lafon and it looks like we want to reconsider this

Transfer-Encoding is hop-by-hop, while Content-Encoding is end-to-end.

This means that if the HTTP implementation is using a proxy, the proxy
will see the Transfer-Encoding: gzip, will unzip it, and not necessarily
forward the request as TE gzip. I don't think this is what we intended
in the WSDL specification. That wouldn't be the case for

So, we should consider binding the {http transfer coding} property to
the HTTP Content-Encoding header. Both can work for SOAP and HTTP
binding. The XML Protocol Working Group even considered defining a new
content encoding for MTOM instead of a mime type but gave up given the
difficulties of introducing a new TE in HTTP.


On Fri, 2007-01-12 at 10:49 -0500, Philippe Le Hegaret wrote:
> On Fri, 2007-01-12 at 14:30 +0530, keith chapman wrote:
> > Hi,
> > 
> > Does the spec state the HTTP header to use when a message is encoded
> > as gzip. I  had a look at section "6.3.2 HTTP Transfer Coding
> > Selection" it does not state anything to this regard. The test
> > framework looks for the header "Transfer-Encoding=gzip" but axis2 uses
> > the header "Content-Encoding: gzip" .
> Given
> [[
>   This [Transfer-Encoding] differs from the content-coding in that the
> transfer-coding is a property of the message, not of the entity.
> ]]
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41
> I believe Transfer-Encoding is the one to use. With the set of value
> available in section 3.6 of the HTTP RFC [1]. Note that "identity" can't
> be used anymore in as a transfer codings, according to the latest
> editors version of the HTTP RFC that includes errata [2].
> Given your question, the spec needs clarification.
> Philippe
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
> [2]
> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#transfer.codings
Received on Tuesday, 16 January 2007 14:51:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:05 UTC