Re: New precondition fields and caching

On Tue, Sep 8, 2020, at 15:12, Mark Nottingham wrote:
> 
> 
> > On 7 Sep 2020, at 4:31 pm, Martin Thomson <mt@lowentropy.net> wrote:
> > 
> > 
> > 
> > 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?
> 
> https://github.com/httpwg/http-core/issues/448

Thanks. 

> I think we use 'request header fields', 'response header fields' and 
> other permutations pretty consistently. Would it address your concern 
> if we made 
> <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.and.trailer.fields> a bit more explicit (i.e., included 'request' and 'response' as limiting modifiers)?

That might help. I think that my concern isn't that serious when I look again though. The definition is definitely implicit, in that you say these are header fields in a section called request fields.

You already have "We refer to some named fields specifically as a "header field" when they are only allowed to be sent in the header section."  That is quite clear there, but the use of that is less so with the phrasing chosen. So whatever you think works best.

Received on Tuesday, 8 September 2020 09:32:01 UTC