RE: BNF for Cache-Control

Julian Reschke wrote:
> Adrien de Croy wrote:
> > Is this intended?  Surely cache-response-directive are only valid for
> > responses, and cache-request-directive for requests?
> >
> > I would have expected something more like:
> >
> >    Cache-Control = "Cache-Control" ":" cache-control-request |
> >                    cache-control-response
> >    cache-control-request = 1#cache-request-directive
> >    cache-control-response = 1#cache-response-directive
> >
> > to enforce separation.
> >
> > Apologies if this is already covered in HTTPbis
> > ...
> 
> There's a limit to what we can (or *want*) express in the ABNF.
> 
> If we made that change, a header instance that combined both request
> and response directives would by syntactically invalid. Would that
> reflect what's really desired and implemented? Shouldn't recipients
> just ignore those directives they don't understand?

A parser using the current grammar will never recognize anything as a
cache-response-directive, because cache-response-directive comes after
cache-request-directive, and cache-request-directive matches all
cache-response-directives, because of its cache-extension alternative. (The
RFC3986 grammar uses a "first-match-wins" parsing rule. Since the HTTP
grammar reuses some of these "first-match-wins" productions, I'm assuming
that the HTTP grammar also requires "first-match-wins" parsing throughout.
Otherwise, it would be ambiguous in at least a few places.)

A grammar like Adrien's suggested is definitely clearer than the current
one. The specification would be even clearer (and, importantly, without
grammar ambiguity) if it treated Cache-Control as separate request- and
response- headers, instead of a single header with two different syntaxes.
That is probably something best looked at after the grammar changes in the
way Julian mentioned a few days ago (looking up the syntax based on the name
of the header).

- Brian