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