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

[Julian Reschke <[e-mail]>]

On 2017-06-25 13:28, Willy Tarreau wrote:
> On Sun, Jun 25, 2017 at 12:50:30PM +0200, Julian Reschke wrote:
>> On 2017-06-25 12:46, Willy Tarreau wrote:
>>> Hi Julian,
>>>
>>> On Sun, Jun 25, 2017 at 12:11:29PM +0200, Julian Reschke wrote:
>>>>      An intermediary MAY drop the informational response. (...)
>>>>
>>>> That seems to contradict a MUST-level requirement in RFC 7231
>>>> (https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)
>>>
>>> Not completely. An intermediary not aware of 103 may map it to 100. If
>>
>> It may do so, but it's not allowed to (IMHO).
> 
> I agree with you but there's probably a difference with what is really
> deployed in field. However I'm now seeing a wording issue here, because
> saying "An intermediary MAY drop the informational response" suggests
> to intermediary implementations that this is permitted. I think that
> using just a warning for server implementations would be more appropriate,
> like "A server should be prepared to see its 103 responses silently dropped
> or altered by some non-compliant intermediaries".

Yup.

>>> the intermediary inserted an "Expect: 100 continue" header field, we
>>> can reasonably imagine that such an intermediary might also drop the
>>> returning 103. This wording in 7231 may even encourage some implementations
>>> to do so : "A proxy MUST forward 1xx responses unless the proxy itself
>>> requested the generation of the 1xx response". Speaking about 1xx here
>>> may be read as "I asked for 100, I'm receiving 1xx so that matches".
>>
>> But that sounds like a bug in the proxy to me. A 103 is not a 100.
> 
> Sure, but it's also suggested that when processing a code XYY that you
> don't know, you can consider that it will act like X00. I'm not

I wouldn't consider that a license to *change* the code though.

> justifying that some might be doing this, just that we need the spec to
> be robust against such bogus behavious *if they exist*. Especially
> interim responses, which have always been tricky to get right
> everywhere :-/
> ...

True, but we shouldn't confuse normative language (which simply can't be 
in conflict with the base spec without additional work) from implementor 
guidance.

> ... >> 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...

Best regards, Julian