Issue Details (XML | Word | Printable)

Key: JERSEY-107
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: mkarg
Votes: 1
Watchers: 0

If you were logged in you would be able to see more operations.

Support for Transfer Encoding

Created: 01/Sep/08 11:25 AM   Updated: 04/Nov/13 05:57 PM
Component/s: core
Affects Version/s: None
Fix Version/s: icebox

Time Tracking:
Not Specified


Operating System: All
Platform: All

Issuezilla Id: 107
Participants: mkarg

 Description  « Hide

HTTP/1.1 describes the technique of Transfer Encoding. The core idea is that
client and server can negotiate for a set of commonly supported compression
mechanisms, of which one will get applied for compression before / uncompression
after the entity transfer. As a result, the costs of a slow transfer is reduced
by investing the costs of applying a possibly complex compression /
uncompression on client and server. The more CPU power exists and the slower or
expensier the line is, the more sense does it make to apply this technique. As
CPU power gets cheaper faster than lines, and as it is nothing application
dependent in Transfer Encoding, it makes sense to support Transfer Encoding as a
internal feature of both, the server and client side implementations of Jersey.

mkarg added a comment - 09/Dec/08 10:48 AM

As JSR311-1.0-fr specifies that Transfer Encoding is to be done by the servlet
container, I want to rephrase my feature request: Please add handling of
Transfer Encoding to the Jersey CLIENT Runtime. Also it would be great if
the client application could register a handler which gets notified by the
Jersey Client Runtime about the progress of the transmission. And it would be
great if the transmission can be cancelled by the client application.