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

Re: Questions in draft-09

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 8 Jan 2014 21:24:12 +0900
Message-ID: <CAPyZ6=L6w=ukDbnDiSSUiPkoN4L3ZZyvVv_448BR3g1O2v+=5w@mail.gmail.com>
To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
Cc: ietf-http-wg@w3.org
2014/01/08 9:19 "Shigeki Ohtsu" <ohtsu@iij.ad.jp>:
>>
>> This really, really needs to be specified.  In one interpretation I
>> recall from somewhere, HTTP2-Settings is lifted from the Upgrade
>> request and played out as though it were a regular frame, causing an
>> ACK to be generated.  That is, as you say, not necessary, but it would
>> be
>
>
> Thanks Martin for opening the issue of #336.
>
>
>>>> 2. How to refuse a large SETTINGS_HEADER_TABLE_SIZE
>>>>   When an endpoint received a large SETTINGS_HEADER_TABLE_SIZE
>>>>    and do not want it, what to do it?
>>>
>>>
>>> We discussed this topic some time ago:
>>>
>>> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0317.html
>>
>>
>> Yes.  Unless there is new information, I'd rather not reopen this
discussion.
>
>
> Thanks Tatsuhiro, I missed that discussion.
>
> But I think that using a smaller header table with a indexing
representation in
> encoding causes a problem even if the static table is not referred.
>
> It is because eviction at the smaller side leads inconsistency of
reference
>  sets between encoder and decoder and differenet header sets are emitted.
> That's why I wrote a withoutindexing representation.
>
> Did I miss something?
>
>>>> 3. Header Ordering(8.1.3.3) and Cookie Compressing(8.1.3.4)
>>
>> Ahh, this needs to be fixed.  Given the *current* choice of delimiter,
>>
>> I think that we need to prohibit the use of 0x0 in Cookie.  Otherwise
>> it will be variously treated as a regular character or as a proxy for
>> "; ".  Alternatively, the most reasonable interpretation is that
>> Cookie is first split on 0x0, then re-merged based on "; ", but I'd
>> argue that there is no reason to be doing this (yeah, you can save a
>> byte for each split, wow, but the complexity cost...).
>
>
> I think the latter is not so complex. Just the order of processing
> need to be defined to avoid confusion.
>

Rethinking about this, and I agree with Shigeki. After all, we are sweeping
values to find 0x0 and split. Maybe one way is that we discourage 0x0
concatenation for cookie (for better compression) , but accept such
headers. After split, concatenate them as if they are sent independently.

Best regards,
Tatsuhiro Tsujikawa

> Regards,
>
>
>
Received on Wednesday, 8 January 2014 12:24:42 UTC

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