HTTP / HTTP4 issue with accept content / content encoding

[Bryce Ewing <br...@gmail.com>]

Hi,

I have had some issues around content encodings, specifically gzipped HTTP
content for an RSS feed.  This is related to:
   
http://camel.465427.n5.nabble.com/Error-with-RSS-component-accessing-gzip-content-td1335918.html#a1543487
but also separate.

When using either HTTP or HTTP4 components to try to solve the issues I was
having for RSS feeds I have found these also don't work in all cases.  It
seems rather strange to me how this is currently setup.

Based on the RFC to let a server at the other end know what content
encodings you accept you send a Accept-Encoding header, e.g. if you only
accept gzip you could send "Accept-Encoding: gzip", if you accept gzip and
identity (i.e. not encoded) then you could send "Accept-Encoding gzip,
identity".  Based on the encodings that you tell the server you accept it
can then choose what to send you in response, and it lets you know this by
setting the Content-Encoding response header.

Where things get a little strange for the http and http4 components is that
they seem to be checking for the Content-Encoding header on the request.  I
initially thought that to perform a request for gzip content the
Content-Encoding header should be set prior to calling the http component,
e.g.:
  from(timerEndPoint)
    .setHeader(Exchange.CONTENT_ENCODING, constant("gzip"))
    .to(httpFeedUrl)
and that maybe it was translated into a Accept-Encoding header.

It seems to me that it would be best to read the response Content-Encoding
header in order to determine whether to decode the stream or not.

Thoughts?

Cheers
Bryce
-- 
View this message in context: http://camel.465427.n5.nabble.com/HTTP-HTTP4-issue-with-accept-content-content-encoding-tp1698061p1698061.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: HTTP / HTTP4 issue with accept content / content encoding

[Willem Jiang <wi...@gmail.com>]

As the HttpProducer need compress the request message, so the http 
component checks the content encoding header before it send the request.

I just wrote a simple test to verify your case, and found its bug of 
HttpComponent. A JIRA[1] is created for tracking this kind of issue.

If you just send a get request, you don't need to set the content 
encoding header,and just set the "Accept-Encoding" header, and the 
HttpProducer should take care the response by checking the response 
content encoding header.

[1] https://issues.apache.org/activemq/browse/CAMEL-2985

Willem
----------------------------------
Apache Camel, Apache CXF committer
Open Source Integration http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang

Bryce Ewing wrote:
> Hi,
> 
> I have had some issues around content encodings, specifically gzipped HTTP
> content for an RSS feed.  This is related to:
>    
> http://camel.465427.n5.nabble.com/Error-with-RSS-component-accessing-gzip-content-td1335918.html#a1543487
> but also separate.
> 
> When using either HTTP or HTTP4 components to try to solve the issues I was
> having for RSS feeds I have found these also don't work in all cases.  It
> seems rather strange to me how this is currently setup.
> 
> Based on the RFC to let a server at the other end know what content
> encodings you accept you send a Accept-Encoding header, e.g. if you only
> accept gzip you could send "Accept-Encoding: gzip", if you accept gzip and
> identity (i.e. not encoded) then you could send "Accept-Encoding gzip,
> identity".  Based on the encodings that you tell the server you accept it
> can then choose what to send you in response, and it lets you know this by
> setting the Content-Encoding response header.
> 
> Where things get a little strange for the http and http4 components is that
> they seem to be checking for the Content-Encoding header on the request.  I
> initially thought that to perform a request for gzip content the
> Content-Encoding header should be set prior to calling the http component,
> e.g.:
>   from(timerEndPoint)
>     .setHeader(Exchange.CONTENT_ENCODING, constant("gzip"))
>     .to(httpFeedUrl)
> and that maybe it was translated into a Accept-Encoding header.
> 
> It seems to me that it would be best to read the response Content-Encoding
> header in order to determine whether to decode the stream or not.
> 
> Thoughts?
> 
> Cheers
> Bryce