- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 30 Oct 2017 14:38:19 +0900
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
2017-10-30 13:50 GMT+09:00 Mark Nottingham <mnot@mnot.net>: > Hi Kazuho, > >> On 30 Oct 2017, at 12:50 pm, Kazuho Oku <kazuhooku@gmail.com> wrote: >> >> Thank you for working on the draft. >> >> I like this approach very much. It is evolutional, and to me seems >> very practical. > > Thanks! > >> >> What we have suffered until today is not being able to reuse a lexer >> for parsing headers. >> >> To me it seems that the draft is trying to solve that issue only, and >> I think that it would be a good approach considering that we have had >> issues in previous attempts that tried to provide other changes at the >> same time. >> >> My comments in-line. >> >> 2017-10-30 9:57 GMT+09:00 Mark Nottingham <mnot@mnot.net>: >>> PHK and I have been talking in the background about how to progress the >>> "Common Headers" work item. >>> >>> Last week we put together a straw-man of what I thought we might want the >>> eventual product to look like. Please have a look; it'd be interesting to >>> see how close/far this is from where we want to go. >>> >>> Note that it *is* pretty thrown together, and there are a couple of TBDs. >>> I'm also certain that the algorithms are buggy as can be. >>> >>> The interesting things to discuss here IMO are: >>> >>> * Are the basic data types offered the right ones? Too many, too few? >>> * Should parameters on parameterised labels be ordered or unordered (since >>> writing that, I've found a use case for ordered)? >> >> I think that the decision should be left up to the user of Structured >> Headers. In other words, I think that the draft should focus on how >> the input should be parsed. > > Seems reasonable to me. Perhaps it would be good to have a non-normative appendix or similar offering guidance to library implementations on things like this. > > >>> * Are the limited levels of structure (most complex being a list of >>> parameterised labels) sufficient? >>> * Is limiting size and number of elements appropriate? Are the limits >>> proposed the right ones (warning: bikeshed)? >> >> My +1 goes to not having limits. Instead, a specification that uses >> Structured Headers should set limits, if that deems appropriate. >> >> My feeling is that it seems awkward to me to have the restrictions in >> Structured Headers, considering the fact that other aspects of HTTP do >> not have. For example, there is no hard limit on the length of an HTTP >> header field value or on the number of HTTP headers. > > The one thing that makes me pause here is how rarely headers specify limits like this if left to their own devices, and how much trouble it can cause because there are different implementation-specific limits imposed. > > Given that, it seems like if we ever want to have some general limits (with the ability for specific headers to tighten them, of course), this is a good time to try. > > But it might be that we decide it's not worth trying. Thank you for your response. I think that it would be a good idea to specify some limits below which we can expect interoperability. Something like JSON defines for floating numbers (i.e., numbers that fit in IEEE754 double are expected to have good interoperability). I am simply against defining the limits as hard limits, since in one way that might be interpreted as a minimum requirement that all implementations must support, at the same time being an unnecessary complication for some of other implementations (you can essentially cap the amount of memory used by header parsing (including Structured Headers) by capping the maximum number of bytes used to transfer all the request headers; so why should we have another limit?). > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > -- Kazuho Oku
Received on Monday, 30 October 2017 05:38:43 UTC