Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Ideas for an output filter for mod_lua
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <20120823224910.577a5ab5@baldur>
Date: Thu, 23 Aug 2012 14:54:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B93635C4-6C73-4B56-BE83-6BCDA302BDE3@gbiv.com>
References: <5034BBE2.4090903@cord.dk>
 <88E2A29E-FB86-4EB1-B224-601EEE861D54@webthing.com>
 <50354E2D.5070408@cord.dk>
 <C0870C00-6630-4E27-975A-DDAFAB477CE0@jellybaby.net>
 <503609B3.5090301@cord.dk>
 <0847B62A-1FAB-445F-804D-7C87114B8823@jellybaby.net>
 <20120823224910.577a5ab5@baldur>
To: dev@httpd.apache.org


On Aug 23, 2012, at 2:49 PM, Nick Kew wrote:

> On Thu, 23 Aug 2012 22:32:20 +0100
> Tim Bannister <isoma@jellybaby.net> wrote:
>=20
>=20
>> That's quite neat, then. I will try to make an actual implementation =
in Lua.
>> The part I found difficult was the interaction with the second =
transfer-encoding, =93chunked=94. Using gzip Transfer-Encoding: implies =
using chunked, because we want to shorten the response and this means =
that the Content-Length definitely doesn't match the size of the HTTP =
response body.
>=20
> gzip is a content-encoding, not a transfer-encoding.

It is both.  Transfer-Encoding is the correct way to implement it.

> That makes it easy to implement: content filters and protocol
> filters work at different levels, so can coexist without trouble.

Except that they aren't standards-compliant because they don't
handle etags correctly.  Content-Encoding works with more clients
but is much harder to implement correctly.

....Roy