hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Berlin <sber...@gmail.com>
Subject Re: Does (or will?) HttpClient handle compressed content ?
Date Sat, 10 Dec 2005 18:28:00 GMT
I'll toss my $0.02 in with Tony and say I fall on the side of having
HttpClient handle compression.  (Perhaps with the upcoming 4.0
re-architecting it could be part of a different module, though.)  My
reasoning behind this is that I view HttpClient as a way to get the
information from the server to the client.  The fact that the data is
compressed seems to me to be an implementation detail of the transfer.
 If the server tells the client it's compressed, the client knows it
can uncompress it and give the user the actual information (not some
representation of it, that the user then has to go and do more work on
to get the actual data).

Whether or not this line of thought fits with the "HttpClient is a
pure HTTP Protocol library" is immaterial to me.  9 times out of 10,
compression is just a detail that the server added on to reduce
bandwidth costs.  The user shouldn't have to know or care about it
(and certainly it seems bad practice to force every user to have to
account for that fact and write duplicate code).  Compression is a
perfect example of something that HttpClient can just 'take care of',
saving the user a lot of trouble.

However ...  because the protocol only allows the server to use a
certain Content-Encoding if the client sent an Accept-Encoding, it
sort of becomes a moot point.  There'll never be a case where the data
is compressed if HttpClient didn't want it to be.  And why would it
want it to be if it can't understand it?

This seems to call for a good 'content-encoding' module that can be a
pipeline for handling various encodings (signalling that the client
accepts it and decoding the server's data).  It'd be entirely
optional, but a good use of additional, common, functionality.

Thanks,
 Sam

On 12/10/05, Thom Hehl <thom@nowhereatall.com> wrote:
> Because the great master Grady Booch taught us that a class should be
> minimalistic and complete. It should contain absolutely everything that
> is essential to it's named purpose and absolutely nothing that isn't.
>
> Compression is a separate function from HTTP. It's not in the spec
> whatsover, just like JPEG, GIF, and shockwave. If you say that you're
> going to put a compression algorithm into the library, then you need to
> put algorithims for all MIME types in there as well and your library
> just became a disaster.
>
> A good HTTP client library should handle everything that is HTTP and is
> a part of the zillion RFCs or other standards that are commonly used.
> Since compression is really a MIME type, it should be handled separately
> from the client library.
>
> Besides, java comes with libraries for handling zip files. Just wrap the
> return value in that.
>
>
> Tony Thompson wrote:
>
> >I thought I would chime in and say that I disagree.  As a user of the
> >HTTP library, why shouldn't I be able to tell the client to do
> >compression, if it can negotiate it with the server?  Then, when I grab
> >the content from a response, I should be able to get the uncompressed
> >content seamlessly.  I think it would also make sense to have the option
> >to get the response content in its compressed form as well.  Doing it
> >that way, that still leaves it totally up to the user if they even want
> >compression and they have access to both the compressed and uncompressed
> >response.  I think that makes more sense than forcing everyone to
> >implement compression themselves.
> >
> >Just my 2 cents...
> >Tony
> >
> >
> >
> >>>>thom@nowhereatall.com 12/10/05 10:42AM >>>
> >>>>
> >>>>
> >FWIW, I agree with you, Oleg.
> >
> >Oleg Kalnichevski wrote:
> >
> >
> >
> >>On Sat, 2005-12-10 at 14:16 +0000, sebb wrote:
> >>
> >>
> >>
> >>
> >>>I've searched the documentation and source, and the only references
> >>>
> >>>
> >to
> >
> >
> >>>zip / compression seem to be in the content-type lists. [Also
> >>>
> >>>
> >searched
> >
> >
> >>>Bugzilla]
> >>>
> >>>Just double-checking:
> >>>
> >>>It seems that HttpClient does not automatically handle compressed
> >>>
> >>>
> >responses.
> >
> >
> >>>Is this the case, or have I missed something?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>This is indeed the case.
> >>
> >>
> >>
> >>
> >>
> >>>Asuming no, are there any plans to include decompression in the
> >>>
> >>>
> >future?
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>No. There are no such plans. HttpClient should not have any content
> >>processing code. Compression / decompression logic can be easily
> >>
> >>
> >built
> >
> >
> >>on top of HttpClient. Anything that has to do with the content
> >>processing does not belong to a generic HTTP library
> >>
> >>Oleg
> >>
> >>
> >>
> >>
> >>
> >>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail:
> >>>
> >>>
> >httpclient-user-unsubscribe@jakarta.apache.org
> >
> >
> >>>For additional commands, e-mail:
> >>>
> >>>
> >httpclient-user-help@jakarta.apache.org
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >>
> >>
> >
> >
> >
> >>For additional commands, e-mail:
> >>
> >>
> >httpclient-user-help@jakarta.apache.org
> >
> >
> >>
> >>
> >>
> >>
> >
> >
> >Thom Hehl
> >Heavyweight Software for Heavyweight Needs
> >www.heavyweightsoftware.com
> >
> >
>
>
> Thom Hehl
> Heavyweight Software for Heavyweight Needs
> www.heavyweightsoftware.com
> --
> "In every revolution, there is one man with a vision."--Jerome Bixby
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message