Hi, I've got a couple of suggestions that I thought might be worth kicking around here.
I think that as an end-user of HttpClient, it demands too much knowledge of RFC2616. People shouldn't have to be aware of gzip-compression or other content-encodings that may be available, unless they want to specifically handle them. For example, Joe Gregorio's excellent httplib2 [1] for Python. >>> import httplib2 >>> response, content = http.request('http://www.apache.org/') Using Wireshark, I can see that the request is made and supports compress and gzip encodings without the client developer having to know RFC2616 intimately or worry about handling the low level details like that. GET / HTTP/1.1 Host: www.apache.org accept-encoding: compress, gzip user-agent: Python-httplib2/$Rev: 259 $ httplib2 also has great in-built cache support and understands ETag / Last-Modified to transparently do conditional GET when required. Should conditional GET be handled by HttpClient? I think that it should; I think Restlet offers support for this. I'm sure there are other comparisons that could be made with other languages / libraries. I know that HttpClient 4 can offer support for gzip compression via a custom protocol interceptor (thanks Oleg!) but my personal view is that adds to the semantic surface area for a user of the API. Are these reasonable feature requests; i.e. 1. Good support for gzip Content Codings [2]. Others can be easily supported as well, but gzip is the most common. 2. Support a private cache / enable transparent conditional GET. Cheers, James [1] http://code.google.com/p/httplib2/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org