- From: Willy Tarreau <w@1wt.eu>
- Date: 2017年8月10日 05:45:41 +0200
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, HTTP Working Group <ietf-http-wg@w3.org>, Dragana Damjanovic <dragana.damjano@gmail.com>
- Message-ID: <20170810034541.GA507@1wt.eu>
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: 2017年5月26日 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