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 15:56:35 +1000
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, Martin Thomson <martin.thomson@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <6B2BCC43-9ECB-45E9-97B5-8B7C347D0A45@mnot.net>
To: Willy Tarreau <w@1wt.eu>
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>.


> 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/
Received on Monday, 14 May 2018 05:57:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC