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 05:46:58
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

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