RE: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Compare to including differing headers between a 200 and a 304, for example -- the RFC says that servers SHOULD NOT emit headers that change the interpretation of the cached content, but that clients MUST merge in any headers the server chooses to emit.  But in practice, every browser has a list of headers it won't let the server change its mind about, and will ignore the server if it tries.  Allowing contradictory information here runs into the same effective problem.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, November 7, 2016 1:03 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: Kazuho Oku <kazuhooku@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

On 7 November 2016 at 18:40, Mark Nottingham <mnot@mnot.net> wrote:
> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an "early" HEADERS followed by the :status etc. in a CONTINUATION.

I don't think that this is a problem.  I mean, for requests it means that routing based on the URL can happen without arbitrary buffering.
That we also did it for responses is perhaps unnecessary, but it's a little bit of certainty and opening the door for progressive generation of headers also opens the door to new classes of ambiguity as well.  Especially since we still allow individual header fields to come in piecemeal.  I think that I prefer Kazuho's approach.

The progressive response means that this is OK for progressive things.
I wouldn't want to see a server change its mind about something; content-type might be hazardous, for example.

Received on Monday, 7 November 2016 18:15:46 UTC