hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Abley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-834) Transparent Content Coding support
Date Mon, 16 Mar 2009 22:41:50 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682497#action_12682497
] 

James Abley commented on HTTPCLIENT-834:
----------------------------------------

1) OK, thanks for the clarification. That pretty much ties with my understanding, but I thought
it was a reasonable approach at the time and seemed in line with recommendations from Java
Concurrency in Practice. I've removed the usage as you suggested.

2) I initially thought you wanted to specify quality values. But you're describing something
similar. I'm still not clear why that requires configuration. If the user doesn't want the
interceptor to indicate to the server that various content codings are supported, the user
can specify their own Accept-Encoding header for the request and the request won't be altered
and the response won't be processed by the new interceptors. Indeed, that behaviour is there
to ensure that it doesn't break any existing clients that may be using an interceptor already
to support this functionality. Although thinking about that, the new interceptor is getting
added before the client has a chance to add an interceptor, so the new ones that I've written
will fire before a user-provided one gets a chance to handle the request response. Is that
the issue? What else am I missing? Can you point me at an example of something similar that
already exists, for configuration parameters?

As as aside, is there any reason why the Javadocs aren't built as part of the site hosted
at apache?

> Transparent Content Coding support
> ----------------------------------
>
>                 Key: HTTPCLIENT-834
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-834
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>          Components: HttpClient
>    Affects Versions: 4.0 Beta 3
>         Environment: Any
>            Reporter: James Abley
>         Attachments: 834.patch
>
>
> I would like to see HttpClient features brought up to parity with other libraries, both
in Java and other languages. c.f. Python's httplib2 (not yet in the standard library, but
many would like to see it in there). That library transparently handles gzip and compress
content codings.
> This issue is to capture possible solutions to providing this sort of innate functionality
in HttpClient, so that users aren't required to know RFC2616 intimately. The HttpClient library
should do the right thing and use the network in the most efficient manner possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message