- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 15 May 2018 15:42:10 +1000
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Willy Tarreau <w@1wt.eu>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
SH doesn't allow empty header fields, FWIW. We also don't have boolean values, but it seems trivial to use an integer. > On 14 May 2018, at 4:35 pm, Kazuho Oku <kazuhooku@gmail.com> wrote: > > Maybe I am missing some context, but the question here (for SH) seems > to me that how we should carry a boolean flag. > > I think that there could be two ways: > 1. use the existence of the header as the flag, as Early-Data draft does > 2. always require the header to carry a boolean value > > I do not mind whichever we choose, but I would prefer having one way > of doing that defined in SH. > > > > 2018-05-14 15:29 GMT+09:00 Mark Nottingham <mnot@mnot.net>: >> >>> On 14 May 2018, at 4:21 pm, Martin Thomson <martin.thomson@gmail.com> wrote: >>> >>> Mark, are you advocating for removing the text around duplicate values and >>> falling back to something like: >>> >>> "If the header field is repeated or contains a value other than "1" it is >>> invalid. An invalid header field SHOULD be disregarded." >> >> As I said at the start, I'm not asking for any changes to the early-data header field; just trying to validate that in theory, SH would be usable for it (if the timing worked out). >> >> Of course, we *can* make changes if we wish. >> >>> There's an interesting question here about how the requirement to discard >>> malformed header fields generates appropriate feedback signals, but I think >>> that you have a fair point. If we stop assuming that we have to deal with >>> actors that fail to implement correctly, then we exert pressure on those >>> actors to comply. And everyone benefits because our code is simpler and >>> more consistent overall. >> >> *If* it's consistent. We're putting mechanisms in place for SH to help that (generic implementations and a test suite); not sure that applies here. >> >> >>> I was initially attracted to the idea that maybe *just this one time* the >>> use case was "special". But that's dangerous thinking. >> >> :) >> >>> One comment for SH. You permit additional constraints on syntax (like >>> ranges on integers). You separately note that if parsing fails the header >>> field is dropped. You should connect the two explicitly. If a header field >>> is valid according to SH, but invalid according to constraints on the >>> specific header field what happens? >>> * it needs to be dropped because malformed header fields are dropped >>> according to SH >>> * the definition of the specific header field needs to define what >>> happens in this case >>> >>> I think that your assumed position here is the former, but that needs to be >>> really crisp. >>> >>> https://github.com/httpwg/http-extensions/issues/623 >> >> Section 2 of the editors' draft already says: >> >> "However, header field authors are encouraged to clearly state additional constraints upon the syntax, as well as the consequences when those constraints are violated." >> >> https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#specify >> >> Happy to take PRs to expand upon that; if not, I'll try to tease it out. >> >> Cheers, >> >> >> >> >>> On Mon, May 14, 2018 at 3:56 PM Mark Nottingham <mnot@mnot.net> wrote: >>> >>>> The general discussion around SH error handling has been that if we're >>> able to establish good interop early on with clear algorithms and a test >>> suite, it's not necessary to have messy post-hoc special casing like we do >>> with many existing HTTP headers. >>> >>>> See also <https://tools.ietf.org/html/draft-iab-protocol-maintenance-00>. >>> >>>> Cheers, >>> >>> >>>>> On 14 May 2018, at 3:36 pm, Willy Tarreau <w@1wt.eu> wrote: >>>>> >>>>> On Mon, May 14, 2018 at 07:00:19AM +0200, Julian Reschke wrote: >>>>>> On 2018-05-14 00:45, Mark Nottingham wrote: >>>>>>> ... >>>>>>>>> And I'm OK with that in this case. Were we to cite structured >>> headers, we >>>>>>>>> would probably want to call out that direct contravention. >>>>>>> >>>>>>> My assumption was that if this spec were using SH, you wouldn't need >>> to say anything beyond 'this is the structure we expect:...". >>>>>>> ... >>>>>> >>>>>> Agreed. If we need a special case for something simple like that, one >>> of the >>>>>> two specs needs to change. >>>>> >>>>> I was trying to figure what other very sensitive header field we have >>>>> which falls in this situation where we don't want to simply ignore nor >>>>> discard it. Transfer-Encoding is one such header field. What we do >>>>> there for non-100% valid requests is to return 400 (cf 7230#3.3.3). >>>>> >>>>> Given the sensitifivity of the Early-Data header field, I'm now more >>>>> convinced that the risk of being too tolerant with it could lead to >>>>> some agents setting it lazily and causing interoperability issues or >>>>> opening replay attacks. Thus I would suggest the following instead : >>>>> >>>>> If a server receives a request message containing more than one >>>>> Early-Data header field or one such header field with a value that >>>>> is not exactly "1", the server MUST respond with a 400 (Bad Request) >>>>> status code and thne close the connection. >>>>> >>>>> Optionally we could try to deduplicate identical values like we already >>>>> do for Content-Length, but I'm inclined to think that it's up to the >>>>> intermediaries which decide to add this field to first verify if another >>>>> one was already present. >>>>> >>>>> I think we should always keep SH in mind when adding new fields, and try >>>>> hard not to open new cans of worms all the time. That doesn't mean it >>>>> will always work but at least we have to try. >>>>> >>>>> Cheers, >>>>> Willy >>> >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >> >> -- >> Mark Nottingham https://www.mnot.net/ >> > > > > -- > Kazuho Oku -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 15 May 2018 05:42:40 UTC