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

That'll work.

Regards

-----Original Message-----
From: Mark Nottingham <mnot@mnot.net>
Date: Saturday, 8 September 2018 at 09:32
To: Thomas Peterson <hidinginthebbc@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: New Version Notification for  draft-nottingham-cache-header-00.txt

    Hi Thomas,
    
    Thanks.
    
    My initial thought is that HIT_STALE covers the case you describe (which sounds a lot like RFC5861 stale-while-revalidate).
    
    I could see adding a parameter that indicates that the cache intends to update the entry asynchronously in the near future; would that work?
    
    Cheers,
    
    
    > On 8 Sep 2018, at 1:26 am, Thomas Peterson <hidinginthebbc@gmail.com> wrote:
    > 
    > I'm very much in favour of this, thanks Mark.
    > 
    > However, the draft doesn't expose a cache-action where a previous request is causing an update in still progress and is serving stale (for example, this is defined in nginx's UPDATING state). I think this should be added, perhaps as "HIT_REFRESH_UPDATING".
    > 
    > Also, no server I've found exposes a value that aligns with "ERROR", how might a 502/504 response code correlate to this, and should this draft specify these response codes be used as a 200 OK along with cache-action of "ERROR" doesn't make sense to me.
    > 
    > Regards
    > 
    > 
    > 
    > From: Mark Nottingham <mnot@mnot.net>
    > Date: Friday, 7 September 2018 at 07:48
    > To: HTTP Working Group <ietf-http-wg@w3.org>
    > Subject: Fwd: New Version Notification for draft-nottingham-cache-header-00.txt
    > Resent-From: <ietf-http-wg@w3.org>
    > Resent-Date: Fri, 07 Sep 2018 06:45:18 +0000
    > 
    > 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: mailto:internet-drafts@ietf.org
    > Subject: New Version Notification for draft-nottingham-cache-header-00.txt
    > Date: 7 September 2018 at 4:41:52 pm AEST
    > To: "Mark Nottingham" <mailto:mnot@mnot.net>
    > 
    > 
    > 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 http://tools.ietf.org.
    > 
    > The IETF Secretariat
    > 
    > --
    > Mark Nottingham   https://www.mnot.net/
    > 
    > 
    > 
    
    --
    Mark Nottingham   https://www.mnot.net/

Received on Monday, 10 September 2018 05:30:49 UTC