Antwort: RE: [Mod_gzip] Request Handling

[Robert Collins]

--=-zFJ6pCbrbEU50whKV4p4
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2003-10-11 at 17:42, TOKILEY@aol.com wrote:
> > So you can NEVER have
> > transfer-encoding: chunked, gzip
>=20
> 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...
>=20
> ...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.
>=20
> If you DON'T 'de-chunk' and you just include the
> ASCII bytes in the compression then you are screwed.

Yep.

> > but you can have
> > transfer-encoding: gzip, chunked
>=20
> or simply...
>=20
> transfer-encoding: gzip
>=20
> or even just...
>=20
> transfer-encoding: identity
>=20
> ...as long as you are CLOSING the connection when done.

Yah.

> Actually...
>=20
> 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.
...
>    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).
>=20
> Huh ??
>
> There IS NO SECTION 3.6.2 in RFC 2616!
>=20
>=20

http://skrb.org/ietf/http_errata.html

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

It's not usable - see the errata page referenced above.

> ...so not sure what the heck if may have had to say about 'identity'
> encoding as it relates to TE.
>=20
> Section 3.5 says...
>=20
>    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.
>=20
> So which section are you suppossed to believe?

3,5 refers to CONTENT codings, not TRANSFER codings. the two are very
different in intent and beahviour.

Cheers,
Rob
--=20
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

--=-zFJ6pCbrbEU50whKV4p4
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/iUJnI5+kQ8LJcoIRAmd9AKDTTEdaLkoH/HC6m2+t4nRcaecM7ACfZmXf
xh6JKzOx7Mi5tfDZ+kjR3vk=
=bI8p
-----END PGP SIGNATURE-----

--=-zFJ6pCbrbEU50whKV4p4--