I think all of this should be handled by setting a parameter saying
"compress my data" somehow, then expecting all the data to be compressed
after that. I thougt we could handle that now, but haven't tried it yet.
Sam Berlin wrote:
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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
