Re: [Technical Errata Reported] RFC7234 (5564)

[Mark Nottingham <[e-mail]>]

Hi Bruce!

See:
  https://httpwg.org/specs/rfc7234.html#cache.control.extensions

Along with this text in sections 3 and 4:
  "Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3."

Cheers,


> On 30 Nov 2018, at 1:21 am, Bruce Adams <[e-mail]> wrote:
> 
> Hi,
>  
> That makes sense. I didn't realise extension could override, particularly in the case of a "MUST".
> For my own education where would I find this policy?
> 
> If I interpret this correctly I can for a ReST service return a stale document and
> "warning 111 response is stale" provided my response also includes "stale-while-revalidate"  from rfc5861.
> 
> Regards,
> 
> Bruec.
> 
> On Tuesday, November 27, 2018, 10:50:57 PM GMT, Mark Nottingham <[e-mail]> wrote:
> 
> 
> REJECT. Extensions are explicitly allowed to override requirements, and making this a SHOULD would be too confusing (as many would read it as "optional").
> 
> 
> 
> > On 27 Nov 2018, at 10:37 pm, RFC Errata System <[e-mail]> wrote:
> > 
> > The following errata report has been submitted for RFC7234,
> > "Hypertext Transfer Protocol (HTTP/1.1): Caching".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5564
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: Bruce Adams <[e-mail]>
> > 
> > Section: 4.2.4
> > 
> > Original Text
> > -------------
> > A cache MUST NOT send stale responses unless it is disconnected
> >  (i.e., it cannot contact the origin server or otherwise find a
> >  forward path) or doing so is explicitly allowed (e.g., by the
> >  max-stale request directive; see Section 5.2.1).
> > 
> > Corrected Text
> > --------------
> > A cache SHOULD NOT send stale responses unless it is disconnected
> >  (i.e., it cannot contact the origin server or otherwise find a
> >  forward path) or doing so is explicitly allowed (e.g., by the
> >  max-stale request directive; see Section 5.2.1).
> > 
> > A cache MAY send stale responses if a cache-control extension for
> > stale content such as "stale-while-revalidate" is used 
> > (see RFC5861).
> > 
> > Notes
> > -----
> > The original text seems to conflict with https://tools.ietf.org/html/rfc5861#section-3
> > 
> > 3.  The stale-while-revalidate Cache-Control Extension
> > 
> >  When present in an HTTP response, the stale-while-revalidate Cache-
> >  Control extension indicates that caches MAY serve the response in
> >  which it appears after it becomes stale, up to the indicated number
> >  of seconds.
> > 
> >    stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds
> > 
> >  If a cached response is served stale due to the presence of this
> >  extension, the cache SHOULD attempt to revalidate it while still
> >  serving stale responses (i.e., without blocking).
> > 
> > See also https://stackoverflow.com/questions/53324538/rest-low-latency-how-should-i-reply-to-a-get-while-an-upload-is-pending
> > 
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --------------------------------------
> > RFC7234 (draft-ietf-httpbis-p6-cache-26)
> > --------------------------------------
> > Title              : Hypertext Transfer Protocol (HTTP/1.1): Caching
> > Publication Date    : June 2014
> > Author(s)          : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> > Category            : PROPOSED STANDARD
> > Source              : Hypertext Transfer Protocol Bis APP
> > Area                : Applications
> > Stream              : IETF
> > Verifying Party    : IESG
> 
> 
> --
> Mark Nottingham  https://www.mnot.net/
> 

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