Antwort: RE: [Mod_gzip] Request Handling

[mod_gzip@lists.over.net]

Hi Rob...
Kevin ( Kiley ) here...

See comments inline below...

You wrote...

> Subj:Re: Antwort: RE: [Mod_gzip] Request Handling
> Date:10/10/2003 9:55:18 PM Central Daylight Time
> From:robertc@squid-cache.org
> Reply-to:mod_gzip@lists.over.net
> To:mod_gzip@lists.over.net
> CC:TOKILEY@aol.com
> File:signature.asc (196 bytes) DL Time (TCP/IP): < 1 minute
> Sent from the Internet (Details)
>
>
> On Sat, 2003-10-11 at 10:42, TOKILEY@aol.com wrote:
>
> > As if this all wasn't complicated enough... it's actually SUPPOSED
> > to be legal to do something like this...
> >
> > Transfer-encoding: chunked, gzip
>
> This isn't legal. RFC 2616 14.41 specifies the list is in order of
> application to the message, and  3.6 says
> " Whenever a transfer-coding is applied to a message-body, the set of
>    transfer-codings MUST include "chunked", unless the message is
>    terminated by closing the connection. When the "chunked" transfer-
>    coding is used, it MUST be the last transfer-coding applied to the
>    message-body. The "chunked" transfer-coding MUST NOT be applied more
>    than once to a message-body. These rules allow the recipient to
>    determine the transfer-length of the message (section 4.4)."
>
> So you can NEVER have
> transfer-encoding: chunked, gzip

You are right. I stand corrected. "chunked" would always
have to be "last" for all of this TE stuff to have any
chance at working correctly...

...and this is all I was really trying to explain in
the previous message... the reason WHY you have to
give mod_gzip permission to 'dechunk' in order to
compress anything that has already assumed it's the
last bus-stop before the response leaves the box
and has added "Transfer-Encoding: chunked" before
the 'response' phase is actually OVER.

If you DON'T 'de-chunk' and you just include the
ASCII bytes in the compression then you are screwed.

> but you can have
> transfer-encoding: gzip, chunked

or simply...

transfer-encoding: gzip

or even just...

transfer-encoding: identity

...as long as you are CLOSING the connection when done.

Actually...

There's always been confusion in the RFC's about whether you can
use the 'identiy' encoding in the Transfer-encoding header but that's
neither here nor there. I've never seen it used. It's just
'semantics confusion' in RFC 2616.

'identity' encoding ( No encoding at all ) is identified as
a 'legal' Transfer encoding at IANA and in section
3.6 of RFC 2616...

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   (section 3.5).

Huh ??

There IS NO SECTION 3.6.2 in RFC 2616!

It doesn't even exist... yet it's referred to in the RFC.

...so not sure what the heck if may have had to say about 'identity'
encoding as it relates to TE.

Section 3.5 says...

   identity
        The default (identity) encoding; the use of no transformation
        whatsoever. This content-coding is used only in the Accept-
        Encoding header, and SHOULD NOT be used in the Content-Encoding
        header.

So which section are you suppossed to believe?

If 'identity' is ONLY supposed to appear in an 'Accept-Encoding:'
field then why is it listed as a valid value for 'Transfer-encoding:'
fields as well... or perhaps the MISSING section 3.6.2 was
supposed to clarify this. Don't know.

I would hate to be coding a downstream proxy or client and
have to decide if the 'identiy' value in a TE field was
'legal' or not if/when it happened to appear.

If you believe section 3.6 and assume that 'identity' encoding
is legal for TE field then I suppose this section...

   Whenever a transfer-coding is applied to a message-body, the set of
   transfer-codings MUST include "chunked", unless the message is
   terminated by closing the connection.

Should actually be changed to say...

   Whenever a transfer-coding is applied to a message-body, the set of
   transfer-codings MUST include "chunked", unless the message is
   terminated by closing the connection OR the transfer-encoding
   value is 'identity'... in which case the value serves as a
   marker only and no transfer-encodings actually have been applied
   to the message-body.

You certainly would never expect to see...

Transfer-encoding: identity, chunked

...because 'identity' actually means no encoding was applied
at all so there's no need to 'chunk' anything.

As I said above, however... this is all just semantics.

Very few Uer Agents would even have the faintest idea what
to do if they saw anything other than 'Transfer-Encoding: chunked'
and most will actually CHOKE if they see more than 1 value
in that header field... no matter what the value(s) or the
order in which they are appear.

> This doesn't change the comment about browser support - but does impact
> the mod_gzip requirements.
>
> Rob

It doesn't impact the mod_gzip 'requirements' at all.

mod_gzip is already 'doing the right thing'. Always has.

The previous message was simply attempting to explain
WHY it needs to 'dechunk' and WHY you have to give
it 'permission' to do so or you won't see any
compressed output.

Later...
Kevin