- From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Date: Wed, 8 Jan 2014 21:24:12 +0900
- To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CAPyZ6=L6w=ukDbnDiSSUiPkoN4L3ZZyvVv_448BR3g1O2v+=5w@mail.gmail.com>
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. > 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. > 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 > Regards, > > >
Received on Wednesday, 8 January 2014 12:24:42 UTC