Re: New precondition fields and caching

> On 7 Sep 2020, at 3:43 pm, Martin Thomson <mt@lowentropy.net> wrote:
> 
> I'm trying to understand whether HTTP can be extended with new preconditions.  I've so many questions.
> 
> If-None-Digest can be used for validation, so it currently defines that 304 (Not Modified) applies when a GET or HEAD request fails the precondition.  However, that seems fraught in ways I didn't originally anticipate.
> 
> Thinking more generally, the 412 (Precondition Failed) status code can be marked explicitly cacheable, but for this to work the server would need to indicate that all responses Vary based on the preconditions that might fail.  That includes not just the 412 status code, but other status codes.  That requirement to include the new precondition in Vary extends to 2xx responses, which could then vary based on the conditional request header field.  
> 
> For example, a request contains a precondition `On: Wednesday` (a bad example perhaps) which ensures that preconditions fail 6 of 7 days of the week.  For this request, both 2xx responses (on Wednesdays) and 412 responses require `Vary: On`.  Without Vary, an intermediary that receives a new precondition `On: Wednesday` could use a cached response and generate a 200 response based on its ignorance of this being a precondition even when the precondition would fail at the origin server.
> 
> If the same applied to If-None-Match, a whole lot would break.
> 
> Assuming that interpretation is valid, how is this reconciled with existing uses of validation?  If-None-Match and If-Modified-Since specifically, which never in practice get recorded in Vary (at least not as far as I can tell).  Is it that we effectively bless these fields and require caches to understand them?

Yes. You effectively need to introduce a new protocol version to introduce a new precondition, if you want to make its handling mandatory. Designing them so that ignoring the precondition doesn't break anything is the only workaround. They are evaluated completely separately from conneg.

> Separately:
> 
> The guidance for new fields suggests that definitions should consider where those fields are applicable.  The current semantics draft just describes each of the existing preconditions as "request header fields", while avoiding being definitional.  There is no text that says addresses the question of where they appear directly, even generic text.  That doesn't seem especially explicit, but is that enough?

Can you link to where you're talking about?


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

Received on Monday, 7 September 2020 06:26:10 UTC