Re: Questions in draft-09

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

Regards,

Received on Wednesday, 8 January 2014 00:17:44 UTC