Re: Semantics of multiple 103s in Early Hints

On Thu, Aug 10, 2017 at 4:01 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> > On 9 Aug 2017, at 8:45 pm, Willy Tarreau <w@1wt.eu> wrote:
> >
> >   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
>
> FWIW +1 from me. You might want to s/will/can/ -- remember, these are
> hints, so the client can selectively ignore any or all of them (I don't
> *think* we want to say that if you pay attention to hints, you have to
> process them all, do we?)
>

My two cents: I agree -- the client should not be forced to process all
hints.

If I may make a small suggestion: try to avoid the word "union". All
examples in the RFC and in this discussion revolve around the Link header,
where the union of Link headers has a sensible meaning. But the RFC doesn't
place any restrictions on the header fields that can appear in a 103
response. Other header fields, such as ETag or Last-Modified, are
single-valued. It's entirely possible that some day, a crazy server or set
of intermediaries will send two 103 responses with different ETag values.
(Why? I don't know, but eventually something like this will happen.) I
would instead say:

   A server MAY emit multiple 103 (Early Hints) responses with additional
   header fields as new information becomes 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 may consider any combination of header fields received in multiple
   103 (Early Hints) responses when anticipating the list of header fields
   expected in the final response.

(Minor changes from Willy's text: "become" -> "becomes", "the union of all"
-> "any combination of")