- From: Willy Tarreau <w@1wt.eu>
- Date: Sun, 25 Jun 2017 13:53:15 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf@ietf.org, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-early-hints@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com
On Sun, Jun 25, 2017 at 01:36:59PM +0200, Julian Reschke wrote: > > > Understood. But is this a requirement or just a suggestion? Does > > > a client > > > need to forget the information from the 103 when it's not repeated in the > > > final response? > > > > Hmmm the text says : > > "This memo defines a status code for sending an informational response > > ([RFC7231], Section 6.2) that contains header fields that are likely > > to be included in the final response" > > > > Thus I think that the final header fields are the real ones, and that > > those sent early are more about hints to help the client get mostly > > prepared. Can there be a conflict between two overlapping header field > > values for the same link ? If so, some text needs to be appended to > > mandate that the final response the the only authoritative one and that > > the interim ones are only here to help fill silence periods on the link. > > I'm interested in the case where the Link appears in the 103 but not in the > final response... I think it will be very common, because I see a cool opportunity here for edge gateways to send a few links regardless of what the origin server thinks about this. I'm even considering implementing this capability into haproxy because I think it can bring some value. So if this is going to have side effects, it would be nice that they are properly estimated. Willy
Received on Sunday, 25 June 2017 11:53:50 UTC