- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 7 Jan 2014 15:33:42 -0800
- 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