Re: New Version Notification for draft-nottingham-cache-header-00.txt

[Kazuho Oku <[e-mail]>]

Hi Mark,

Thank you for the clarifications.

I agree that we need a structured way to emit what's happening in the
caches, and that the proposed Cache header is in the approach we
should adopt.

I still feel it to be unfortunate for the fact that the features
overlap between the two header fields, but hopefully browsers would
add JavaScript API to the Cache header and then things would become
optimal.

2018年11月13日(火) 13:57 Mark Nottingham <[e-mail]>:
>
> Hi Kazuho!
>
> > On 13 Nov 2018, at 2:23 pm, Kazuho Oku <[e-mail]> wrote:
> >
> > Hi Mark,
> >
> > Thank you for the draft.
> >
> > I like the Cache header it because it standardizes what we have been
> > doing, and it has clear structure that can be used by the client to
> > collect stats.
> >
> > OTOH, I wonder how we should use it in conjunction with Server-Timing header.
> >
> > In my view, both the Cache header and the Server-Timing header allows
> > caches and intermediaries to set arbitrary information related to
> > processing.
> >
> > For example, I think the example described in the I-D (quoted below
> > using separate Cache header for each element) can be represented also
> > by using the Server-Timing headers as show below.
> >
> >    Cache: HIT_FRESH; node="reverse-proxy.example.com:80";
> >        key="https://example.com/foo|Accept-Encoding:gzip"
> >    Cache: HIT_STALE; node="FooCDN parent"; fresh=-45; age=200; latency=3,
> >    Cache: MISS; node="FooCDN edge"; fresh=-45; age=200; latency=98
> >
> >    Server-Timing: hit-fresh; node="reverse-proxy.example.com:80";
> >        key="https://example.com/foo|Accept-Encoding:gzip"
> >    Server-Timing: hit-stale; node="FooCDN parent"; fresh=-45; age=200; dur=3
> >    Server-Timing: miss; node="FooCDN edge"; fresh=-45; age=200; dur=98
> >
> > I do not think that having both Cache and Server-Timing is a bad idea.
> > However I would like to see a clarification on how they should be
> > used, especially because their features are IMO overlapping
> > (especially the `latency` and `dur` attributes).
>
> Server-Timing is designed for *application specific* metrics; it's automagically slurped up by browsers for inclusion in their developer tools, etc. Effectively, it doesn't have any semantics beyond "whatever metrics you want to put in here will show up over there."
>
> Cache is designed for generic HTTP caching semantics; its value is in that its values mean the same no matter what application you use them with. By default browser dev tools don't display it, but there's no reason they couldn't if they wanted to -- and because it has defined semantics, if they did, they'd be able to integrate it into what they show the developer more deeply / accurately.
>
> If we used Server-Timing for this use case, we'd be effectively squatting on a bunch of metric names for applications, and hoping we wouldn't have a clash. I think encouraging CDNs, reverse proxies and forward proxy caches to use Server-Timing is Probably Not Great.
>
> Also -considering that 95% of the effort here is going to be defining the semantics, I'm not too worried about the extra effort of defining a new header (especially since we're using Structured Headers :)
>
> Cheers,
>
>
> >
> > 2018年9月7日(金) 15:48 Mark Nottingham <[e-mail]>:
> >>
> >> FYI; IMO it's past time to standardise x-cache and have a real spec for it.
> >>
> >> This is a straw-man, based on a bit of research on existing implementations.
> >>
> >> Pretty version at:
> >>  https://mnot.github.io/I-D/cache-header/
> >>
> >> Comments? I think the primary audience here is proxy cache and CDN vendors, and their users.
> >>
> >> Cheers,
> >>
> >>
> >>
> >> Begin forwarded message:
> >>
> >> From: [e-mail]
> >> Subject: New Version Notification for draft-nottingham-cache-header-00.txt
> >> Date: 7 September 2018 at 4:41:52 pm AEST
> >> To: "Mark Nottingham" <[e-mail]>
> >>
> >>
> >> A new version of I-D, draft-nottingham-cache-header-00.txt
> >> has been successfully submitted by Mark Nottingham and posted to the
> >> IETF repository.
> >>
> >> Name: draft-nottingham-cache-header
> >> Revision: 00
> >> Title: The Cache HTTP Response Header
> >> Document date: 2018-09-07
> >> Group: Individual Submission
> >> Pages: 7
> >> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-cache-header-00.txt
> >> Status:         https://datatracker.ietf.org/doc/draft-nottingham-cache-header/
> >> Htmlized:       https://tools.ietf.org/html/draft-nottingham-cache-header-00
> >> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-cache-header
> >>
> >>
> >> Abstract:
> >>  To aid debugging, HTTP caches often append headers to a response
> >>  detailing how they handled the request.  This specification codifies
> >>  that practice and updates it for HTTP's current caching model.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
> >
> > --
> > Kazuho Oku
>
> --
> Mark Nottingham   https://www.mnot.net/
>


-- 
Kazuho Oku