- 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>
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 >
Received on Tuesday, 16 January 2007 14:51:13 UTC