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

Re: Questions in draft-09

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 7 Jan 2014 15:33:42 -0800
Message-ID: <CABkgnnUiW_T8UX8empeLBEnizoeAa9JmRAKN48=u__+VJ=FaYg@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Shigeki Ohtsu <ohtsu@iij.ad.jp>, HTTP Working Group <ietf-http-wg@w3.org>
On 7 January 2014 08:54, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
>> 1. Synchronization of HTTP2-Settings
>>  HTTP Upgrade is still in the spec.
>>  Are the values of HTTP2-Settings is acked and synchronized at
>>  the time of 101 response?  There is no need for endpoints to
>>  send and wait for a SETTINGS-ACK of HTTP2-Settings Header.
>>
>
> My understanding is HTTP2-Settings are implicitly ACKed.
> The whole point of HTTP2-Settings is inform settings to the remote endpoint
> without
> delay.
> I think it is not so hard for the implementation to apply the settings at
> the initialization.

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

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

>> 3. Header Ordering(8.1.3.3) and Cookie Compressing(8.1.3.4)
>>  An encoded cookie header can contain 0x0 in its value though it is
>>  not comma-separated lists and its ordering is not significant.
>>  In this case, is the cookie value splited and joined with '; '
>>  into a single cookie header?
>>
>
> My understanding is that the spec only requires concatenation of cookie
> values with "; "
> if they are sent separately in independent header field.
> If they are ever sent in concatenated with 0x0 delimiter in one header
> field, then
> rule 8.1.3.3 is applied and we are not going to concatenate them.

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...).
Received on Tuesday, 7 January 2014 23:34:10 UTC

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