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: Mark Nottingham <mnot@mnot.net>
Date: Mon, 14 May 2018 16:29:02 +1000
Cc: Willy Tarreau <w@1wt.eu>, "Julian F. Reschke" <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DC5ED7A8-9424-4405-BF03-C8BB2252D455@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>

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


Happy to take PRs to expand upon that; if not, I'll try to tease it out.


> 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/
Received on Monday, 14 May 2018 06:29:34 UTC

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