- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 7 Feb 2021 21:59:35 +1300
- To: ietf-http-wg@w3.org
On 6/02/21 3:34 pm, Mark Nottingham wrote: > Hey Greg, > > My .02 - > >> On 5 Feb 2021, at 7:16 pm, Greg Wilkins 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. > With my web-dev hat on it is quite common for CMS controlled sites to have a huge mix of modification times on scripts and content sources. It is a huge pain to calculate a reliable L-M before output in this environment. It would much cleaner to (be able to) accumulate a modification time across the scripts and dump a Trailer header with the true L-M value. > 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. > Ack. No need for Age at all on freshly generated content use-cases. > 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. > Very much agreed on deprecating Expect. Though the value limit on max-age is smaller than possible Expect values. So there is a use-case for extremely long duration archiving to use Expect. Amos
Received on Sunday, 7 February 2021 09:03:24 UTC