Henri Gomez wrote:
    Actually, they are both equivalent.

    I'll see how we could make use ByteChunk with JDK code for now.


    I've already started experimenting.


Thanks to send me a note when code will be available.

I'll could add some code to mimic mod_deflate ie :

- compress only certain type of mimes (ie only text/html)
- desactivate it for some browsers
I think I said a few mistakes in the previous emails.

To summarize:
- transfer-encoding allows a protocol level compression; that's what I was planning to add to Coyote (see general transfer encoding, section 4.5)
- content-encoding does the same, but is considered application layer (see entity header fields, section 7.1)

(I'm quite sure I knew that really well a few months ago, but forgot about the subtle difference, since actually, both do the exact same thing to the entity body)

The "problem" is that, although clients support content-encoding, they don't care about transfer-encoding.

So actually, to be really clean, you would need two places with compression code:
- in Coyote HTTP/1.1, to handle transfer-encoding
- in the adapter (or somewhere similar) to handle content-encoding

Of course, since the two do the same, I don't see any reason to be overly fancy, and I'll add the compression code (well, the first draft) in Coyote HTTP/1.1 for now, as the filtering model makes the implementation somewhat cleaner.

As a side note, it would be good if the Servlet specification marked the headers from section 4.5 as "use at your own risk" headers (and esp trailer, transfer-encoding, connection).

Remy


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to