ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

2017-06-25 06:53:35
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

<Prev in Thread] Current Thread [Next in Thread>