On Sep 5, 2008, at 6:04 PM, Markus KARG wrote:
> Paul,
>
> it is always great to look at your contributions! Thanks for
> providing this!
> :-)
>
> For "Transfer-Encoding" I think the correct way to deal with is to
> split the
> discussion into client and server. For the server side I agree with
> you that
> it is up to the container to provide this, since it is a simple
> transports
> problem but not related to the content resource itself; so GlassFish
> should
> provide this. For the client side I think that the Jersey Client API
> should
> support it, since there is nothing like a client container outside
> of the
> Java EE world.
I have to double check, but i wonder if HttpURLConnection supports it.
I don't think it does. I get the impression that TE is not supported
that much. A browser such as Firefox does not send the TE header.
So we could have a separate TE filter that is used internally (not
publicly, as it should always be the last filter) to support decoding
of response bodies (and could be configured to support encoding of
requests).
> The Jersey Client should transparently support compressed
> transports so the client application has nothing to deal with, and the
> client application should have a means to participate in chunked
> transports
> to be able to present a progress bar and let the user cancel further
> transportation (e. g. for video transfers, binary downloads, etc.).
>
Yes, there is an issue for monitoring progress, cancelation is a good
point.
Paul.
> Thanks!
> Markus
>
>> -----Original Message-----
>> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
>> Sent: Freitag, 5. September 2008 17:52
>> To: users_at_jersey.dev.java.net
>> Subject: [Jersey] Support for Content-Encoding, Acccept-Encoding
>> "gzip"
>> filters
>>
>> Hi,
>>
>> I have just added client and server-side filters to support Content-
>> Encoding and Accept-Encoding for values of "gzip". I did not want to
>> support "Transfer-Encoding" at the moment, the reason is i am not
>> sure
>> if it will interfere with the containers, which are better placed to
>> support this.
>>
>> Probably the best way to show this is to look at a unit test [1].
>>
>> This works for entities sent from the client to the server and for
>> entities sent from the server to the client.
>>
>> A client or service can override the behavior by adding a "Content-
>> Encoding" header of "identity" such that entities will not be
>> compressed.
>>
>> A client can configure request entity compression such that entities
>> are only compressed if a "Content-Encoding" header is present with a
>> value of "gzip".
>>
>> The client will always send an "Accept-Encoding" of "gzip" and the
>> server will always compress if gzip is acceptable.
>>
>> I suppose this could be improved to work in the presence of multiple
>> layers of Content-Encoding but that is quite a rare thing.
>>
>> Paul.
>>
>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/trunk/jerse
>> y/jersey-
>> tests/src/test/java/com/sun/jersey/impl/container/grizzly/
>> GZIPContentEn
>> codingTest.java
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>