Re: SETTINGS error handling

Clarification:
If you were meaning to say that the server/client should close the
connection, etc. upon receipt of bad settings, then I wholly agree.

The client shouldn't bother to validate data that it won't interpret,
however, which is what I was saying very poorly in the last email.

-=R
On Jul 16, 2013 9:26 AM, "Roberto Peon" <grmocg@gmail.com> wrote:

> 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
>>>
>>>
>>