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

Re: Getting to Consensus: CONTINUATION-related issues

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 18 Jul 2014 18:40:20 +0000
To: Martin Thomson <martin.thomson@gmail.com>
cc: Michael Sweet <msweet@apple.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6112.1405708820@critter.freebsd.dk>
In message <CABkgnnVPVSXVU+YPvCgjZ1vnbOQ++xn_FfWqMw8Wcr4A0ZVhow@mail.gmail.com>
, Martin Thomson writes:
>On 18 July 2014 11:20, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> I don't think it says anywhere that you cant *send* the block, but if
>> you do, you should expect it to get rejected.
>I hadn't considered that interpretation at all.
>I can't see that working out well.  I'd have thought that if you set a
>limit of 10k, then treating anything that exceeds that as a connection
>error is the logical conclusion.  Otherwise, you have to process more
>than you said you wanted to receive, just to maintain a consistent
>compression state.

I'd expect behaviour in this area to develop and depend on field

I really don't think requests (or responses!) exceeding the limit
are going to happen outside attack-scenarios.

And setting or no setting, receivers will have limits, the only
difference is that we tell senders about them.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 18 July 2014 18:40:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC