W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Support for gzip at the server #424

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Fri, 14 Mar 2014 15:58:10 -0500
Message-ID: <CACuKZqHHRmeAjoG7EGowbeS3o35OYm3v0UEJpzkGGtFGF=tc4w@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Patrick McManus <pmcmanus@mozilla.com>
On Fri, Mar 14, 2014 at 1:21 PM, Roberto Peon <grmocg@gmail.com> wrote:
> Compressed uploads isn't a new feature, but it has poor interop.
> This would fix the interop problem.

RFC2616: All HTTP/1.1 applications MUST be able to receive and decode
the "chunked" transfer-coding

I was fooled by the stern language and implemented it in my server -
apparently for nothing :(

>
> On Mar 14, 2014 10:54 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>
>> On 14 March 2014 10:42, Roberto Peon <grmocg@gmail.com> wrote:
>> > 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.
>>
>> Not that it wouldn't work, but that sounds a little too much like a
>> new feature to me.
Received on Friday, 14 March 2014 20:58:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC