Subject: Questions in draft-09

From: Shigeki Ohtsu <[email-masked]>
Date: Wed, 08 Jan 2014 01:15:18 +0900

Hi, I have a few questions on draft-09.

They are trivial and not serious but need to be clarified
in the draft for implementation.

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.

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?

 a) The endpoint does not send SEETINGS-ACK, but it may cause
    a SETTINGS_TIMEOUT error.
 b) The endpoint sends SETTINGS-ACK but does not allocate a large
    header table and use only LiteralHeaderWithoutIndexing in
    encoding instead.
 c) others?

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?

Regards,

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 8 Jan 2014 01:54:15 +0900

Hi,

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

>     header table and use only LiteralHeaderWithoutIndexing in
We discussed this topic some time ago:

http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0317.html

>  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<http://tools.ietf.org/html/draft-ietf-httpbis-http2-09#section-8.1.3.3>
is
applied and we are not going to concatenate them.

Best regards,

Tatsuhiro Tsujikawa

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Jan 2014 15:33:42 -0800

> I think it is not so hard for the implementation to apply the settings at

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

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

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

---

From: Shigeki Ohtsu <[email-masked]>
Date: Wed, 08 Jan 2014 09:17:17 +0900

> ACK to be generated.  That is, as you say, not necessary, but it would

Thanks Martin for opening the issue of #336.

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

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

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 8 Jan 2014 09:48:38 +0900

>  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

---

From: Shigeki Ohtsu <[email-masked]>
Date: Wed, 08 Jan 2014 10:03:13 +0900

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

Oh, this encoding procedure works fine to be consistent reference sets.
Thanks.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 8 Jan 2014 21:24:12 +0900

> 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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jan 2014 08:47:55 -0800

On 8 January 2014 04:24, Tatsuhiro Tsujikawa <[email-masked]> wrote:
> concatenation for cookie (for better compression) , but accept such headers.
> After split, concatenate them as if they are sent independently.

That's a reasonable conclusion.  I'll make the change, noting that the
entire concatenation issue isn't completely sealed.  I hope that we
can resolve that in Zurich, along with this.