- From: Willy Tarreau <w@1wt.eu>
- Date: Sun, 25 Jun 2017 12:46:29 +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
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 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". > Server response: > > HTTP/1.1 103 Early Hints > Link: </style.css>; rel=preload; as=style > Link: </script.js>; rel=preload; as=script > > HTTP/1.1 200 OK > Date: Fri, 26 May 2017 10:02:11 GMT > Content-Length: 1234 > Content-Type: text/html; charset=utf-8 > Link: </style.css>; rel=preload; as=style > Link: </script.js>; rel=preload; as=script > > <!doctype html> > [... rest of the response body is ommitted from the example ...] > > 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. Regards, Willy
Received on Sunday, 25 June 2017 10:47:11 UTC