- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 16 Jul 2013 09:26:48 -0700
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNexmQ40N-imoNYkCSEttYsUqjLzeHr1Yvz-Brp1AfoiMw@mail.gmail.com>
I think that knowledge client-side of things like that is unwarranted complexity -- the server must sanity check that data anyway to deal with malicious clients, or, in the case of port-80 checksum "failures" which have allowed corrupted bits through. -=R On Jul 16, 2013 8:35 AM, "Tatsuhiro Tsujikawa" <tatsuhiro.t@gmail.com> wrote: > +1 for strict validation. > > Regarding validation for SETTINGS, how about validating the values in > SETTINGS frame? > > For example, the value in SETTINGS has unsigned 32 bit and it means > SETTINGS_INITIAL_WINDOW_SIZE > could have, say, 2^31, which is invalid for flow control. > http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-6.9.1 says > if such value is received in > WINDOW_UPDATE frame, it must be responded with FLOW_CONTROL_ERROR. > But it does not say about SETTINGS frame for invalid window size (it may > infer that but still). > I think it would be good to add some error handling of values on SETTINGS > frame reception. > > Best regards, > > Tatsuhiro Tsujikawa > > > On Tue, Jul 16, 2013 at 9:22 PM, Amos Jeffries <squid3@treenet.co.nz>wrote: > >> On 16/07/2013 10:20 a.m., Martin Thomson wrote: >> >>> On 15 July 2013 12:44, Patrick McManus <pmcmanus@mozilla.com> wrote: >>> >>>> I'm wondering why the text proscribes error handling of MUST ignore in >>>> response to violation of the MUST NOT send provision. >>>> >>> I think that someone either caught Postel's DIsease, or is in remission. >>> >>> Can we either change it to PROTOCOL ERROR (preferred) or just be silent >>>> on >>>> handling of the error? >>>> >>> PROTOCOL_ERROR seems appropriate. >>> >>> Opened: >>> https://github.com/http2/**http2-spec/issues/174<https://github.com/http2/http2-spec/issues/174> >>> >> >> +1. And double that for more strictness everywhere. >> >> >> Amos >> >> >
Received on Tuesday, 16 July 2013 16:27:15 UTC