W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: draft-ietf-httpbis-replay-03, "5.1. The Early-Data Header Field"

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Mon, 14 May 2018 15:35:22 +0900
Message-ID: <CANatvzzQDF4M06CXeHusywTsWK66YO4R1bHH1f6bHeiqJCTsdQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
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>
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
Received on Monday, 14 May 2018 06:35:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC