Re: 103 Early Hints and Caching Intermediaries

Hi Willy,

you are right. It is probably not very useful to send a Cache-Control header in a 103 to
announce the cacheability of the upcoming response in advance. So we could consider
the header "free" to define it to be applied to the 103 itself.

An example could look like this:

 HTTP/1.1 103 Early Hints
 Cache-Control: public, max-age=86400
 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
 Cache-Control: private
 Set-Cookie: …

Or did you think of a cache control extension as in RFC 7234 #5.2.3? Something like
this:

 Cache-Control: private, early-hint="intermediary, 3600"

(early-hint="public, max-age=3600" would be more readable, but probably dangerously
to mis-parse).

Best regards,
Felix

> Am 01.08.2017 um 23:04 schrieb Willy Tarreau <w@1wt.eu>:
> 
> Hi,
> 
> On Tue, Aug 01, 2017 at 10:15:50PM +0200, Felix Hassert wrote:
> (...)
>> To avoid "guessing" in intermediaries, we could define a special Cache Control
>> header field accompanying the 103 status, such as "Early-Hint-Control". An
>> origin could then define a 103 to be cacheable in a proxy server or cache. For
>> subsequent requests the stored 103 could be sent downstream regardless of
>> whether the final response is public or private.
>> 
>> The header field could follow the Cache-Control semantics. The "public" and
>> "max-age=N" directives seem appropriate. A proxy server would have to store the
>> Early Hint information apart from regular responses (e.g. 200) to not confuse it
>> with a final response. When the field "Early-Hint-Control: public" is not
>> present, the 103 response should not be stored.
> 
> Why not simply use cache-control and define its validity with 103 ? I think
> that your use case makes a lot of sense, though in terms of cache, it's
> very special in that this cache would probably aggregate all Link header
> fields retrieved over possibly multiple 103 responses, never any payload,
> and would return them upon further requests.
> 
> Regards,
> Willy

Received on Wednesday, 2 August 2017 21:42:44 UTC