Re: Questions in draft-09

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.

If referenced entry is going out of scope in smaller side (only happens in
encoder side), emit indexed repr to toggle it off from the reference set.
It means some emissions of indexed repr used to be made in larger buffer on
eviction should also be made at the boundary of smaller one.
I implemented this scheme in nghttp2 and works well. FYI, the deflatehd
tool in nghttp2 has this option.

Best regard,

Tatsuhiro Tsujikawa

> 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.
>
> Regards,
>
>
>