W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

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

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 25 Jun 2017 13:28:42 +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
Message-ID: <20170625112842.GA29052@1wt.eu>
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".

> > 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
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 :-/

> > > 
> > > The example suggests that early hints are repeated in the final response. Do
> > > they have to, actually?
> > 
> > If we imagine that clients ignore 103 or that intermediaries occasionally
> > drop it, I think it's desirable to send them. Said differently, the 103
> > response prepends a copy of the Link header fields that the final response
> > is supposed to present to help the client fetch them earlier.
> > ...
> 
> 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.

Willy
Received on Sunday, 25 June 2017 11:29:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC