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

Re: Support for gzip at the server #424 (Consensus Call)

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 18 Mar 2014 10:04:16 -0700
Message-ID: <CAP+FsNfxe4s0gdGDdzXDDwGQO-VTV0Wj3geNVNtxVLm8YK7x9Q@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Note that this is true regardless of whether or not compression is in use--
anything doing chunked entity-body suffers from this when gatewaying to a
1.0 server.
-=R


On Tue, Mar 18, 2014 at 9:14 AM, Daniel Sommermann <dcsommer@fb.com> wrote:

> I believe the issue with gatewaying to 1.0 is that the gateway would have
> to buffer the entire body and then decompress (leading to memory DOS).
> Request bodies cannot be terminated by EOF, unlike repsonse bodies, so a
> streaming approach wouldn't be possible as it is for server -> client 1.0
> gatewaying. Even if it were, it would force the gateway to close the server
> connection, which could be considered a type of DOS as well.
>
> Although this idea is nice, I think we can pass for now.
>
>
> On 03/18/2014 12:03 AM, Julian Reschke wrote:
>
>> On 2014-03-18 04:50, Mark Nottingham wrote:
>>
>>> It sounds like we have consensus to close #424 with no action. Anyone
>>> have a problem with that?
>>>
>>
>> Yes.
>>
>> I believe we're giving up too early.
>>
>> HTTP/1.1 already requires servers to handle chunked encoding in requests:
>>
>>   "All HTTP/1.1 applications MUST be able to receive and decode the
>> "chunked" transfer-coding, and MUST ignore chunk-extension extensions they
>> do not understand." (RFC 2616, 3.6)
>>
>> So gatewaying to 1.1 shouldn't be a problem at all, as no buffering is
>> needed.
>>
>> If gatewaying to 1.0 servers is the problem than we seriously should
>> consider giving up on *that* goal. Speaking of which - why *exactly* is
>> gatewaying to 1.0 a problem?
>>
>> Best regards, Julian
>>
>>
>>
>>
>>
>
>
Received on Tuesday, 18 March 2014 17:04:46 UTC

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