Re: New precondition fields and caching

On Mon, Sep 7, 2020, at 16:25, Mark Nottingham wrote:
> > 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.

Shouldn't the specification say that explicitly?
 
> > 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?

https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#preconditions says:

> A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource. 

It says "request header fields" here and in the definition of each, but it doesn't really say that these fields are only valid when in request headers anywhere that I can see.

Received on Monday, 7 September 2020 06:32:09 UTC