Re: Semantics of multiple 103s in Early Hints

Hi Kazuho,

On Thu, Aug 10, 2017 at 09:38:59AM +0900, Kazuho Oku wrote:
> 2017-08-09 12:43 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> > OK so let's get back to the text. My previous concern was a lack of
> > fluidity in your proposed updated sentence. Now I get a better idea of
> > your intent, I'll see if I can propose to slightly adapt it to keep the
> > same spirit without introducing intermediaries into the mix.
> 
> Thank you very much. I am looking forward to seeing the text.
> 
> FWIW, please let me restate my position that the "alternative
> approach" is not what we should permit in Early Data for two reasons;

s/Early Data/Early Hints ;-)

> i) it introduces a rule specific to how multiple 103 should be handled
> (which could be considered as a non-editorial change), ii) such rule
> is not ideal compared to adding precedence to the preload links.

I agree with you. Still it's a bit normal that we have to specify how
header fields have to be handled because in previous 1xx (101 aside),
they were ignored.

How about replacing this :

   Since the nonexistence of a header field within a 103 (Early Hints)
   response does not indicate the absence of that header field in the
   final response, a server can omit a header field that was included
   in one 103 (Early Hints) response in the following 103 (Early Hints)
   responses, even when it is still anticipated that the header field
   will be part of the final response.
   What a client would expect in the final response is a union of the
   header fields that were found in the multiple 103 (Early Hints)
   responses.
 
With this :

   A server MAY emit multiple 103 (Early Hints) responses with additional
   header fields as new information become available while the request is
   being processed. It does not need to repeat the fields that were
   already emitted, though it is doesn't have to exclude them either. The
   client will consider the union of all header fields received in multiple
   103 (Early Hints) responses when anticipating the list of header fields
   expected in the final response.

I think that adding an example like this one would cover all situations :

  HTTP/1.1 103 Early Hints
  Link: </main.css>; rel=preload; as=style

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </main.css>; rel=preload; as=style
  Link: </newstyle.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

(style.css not used, replaced with newstyle.css, and list delivered over
multiple responses).

I'd be tempted to in fact remove the section about mutiple 103 and fold
that text along the previous one before the example, it would make it
even clearer.

Cheers,
Willy

Received on Thursday, 10 August 2017 03:46:07 UTC