Tranfer-Encoding vs Content-Encoding

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

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

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.

Philippe

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
>