Re: Cache control in trailers?

Hey Greg,

My .02 -

> On 5 Feb 2021, at 7:16 pm, Greg Wilkins <gregw@webtide.com> wrote:
> 
> So Mark... your original proposal was just about the Cache-Control field.   Do you still think that it is only that field that needs support in trailers?

I never said it was the *only* field that needs support in trailers. However, I believe it's most realistic to focus on a defined use case that has limited impact on implementations, rather than trying to boil the ocean of moving buffering between different parties in the protocol. 


>  What about Set-Cookie, Last-Modified, ETag, Retry-After, Age, Expires, etc.   aren't these fields also affected by the use-case you have outlined?   Do you still think a single field proposal is sufficient or is a more general solution needed?

I think the property that PHK pointed out -- giving more flexibility for tracking -- is a great argument against doing anything to make Set-Cookie more useful.

As was already pointed out, ETag can be carried in a trailer today; it just remains for implementations to support it. I suppose we could update Core so that Last-Modified can be too, but I don't think the use case is as compelling.

Retry-After isn't terribly useful for 99%+ of the web, and isn't supported in browsers AFAIK, so it's not very interesting.

Updating Age doesn't make sense; you need it to be as reliable as possible, and adding doubt about that is just going to make things worse.

Expires - *shrug* I guess. I'd rather kill it in favour of CC: max-age -- again, we should think about what behaviours we're encouraging.

As discussed, the elephant in the room that you don't mention is the status code -- but the problem is that a variety of behaviours are triggered by status codes, some specified, some not. In contrast, Cache-Control is targeted just at caches, and so you can reason about changes to it much more easily.

Cheers,



--
Mark Nottingham   https://www.mnot.net/

Received on Saturday, 6 February 2021 02:34:39 UTC