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
