Re: Support for gzip at the server #424

Implementation experience here says that many servers barf if they don't
get content-length for an upload.

imho, the simple solution is to mandate the presence of a header that
indicates the uncompressed content-length when sending compressed data on
http/2. This is generically useful in many applications in both directions.
-=R


On Fri, Mar 14, 2014 at 10:06 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> receiving chunked requests is not supported with a high enough certainty
> that anyone yet wants to send them in a generic web context. (apps that
> know their server's capabilities apriori are a different story). HTTP/2
> negotiation at first seems to make that easier, but supporting easy
> gatewaying back to http/1.0 makes it hard again :(
>
> as much as I would really like this feature, I think its reasonable not to
> include it.
>
>
> On Fri, Mar 14, 2014 at 5:52 PM, Bjoern Hoehrmann <derhoermi@gmx.net>wrote:
>
>> * Martin Thomson wrote:
>> >On 14 March 2014 02:20, Roland Zink <roland@zinks.de> wrote:
>> >> ISIZE is in the footer and not the header.
>> >
>> >So that leads me back to the original conclusion.  Since
>> >intermediation from 2 to 1.1 will require the Content-Length and
>> >extracting that from a gzip'd body would require buffering an entire
>> >request, I'm inclined to say that this is too hard.
>>
>> It would help if you explain why you think Content-Length is needed in
>> this scenario. `Transfer-Encoding: chunked` is supported by servers and
>> intermediaries. Likely not perfectly, but if that is the concern we
>> should make that very explicit.
>> --
>> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>>
>>
>