All new headers should be RFC8941 Structured Field Values

[bblfish]

I have just implemented an RFC8941 parser to support Signing Http Messages IETF draft, so I thought I'd pass on my new found knowledge here.

The Structured Header Fields RFC recommends all new headers to follow that standard. An overview of the reasons for it are given in this blog post. There are over 10 implementations in various languages listed here. And the IETF is working on a binary version at present so that headers can work better with HTTP/2 and HTTP/3.

One of the advantages is that it can make defining new header fields a lot easier, as well as allowing HTTP libraries to automatically parse new hearders on a first pass using that mode. It makes debugging easier too.

So given that and while it is fresh in my mind let me look at WAC-Allow with BNF

wac-allow        = "WAC-Allow" ":" OWS #access-param OWS
access-param     = permission-group OWS "=" OWS access-modes
permission-group = 1*ALPHA
access-modes     = DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS DQUOTE
access-mode      = "read" / "write" / "append" / "control"

An example of such a header would be:

WAC-Allow: user="read write"
WAC-Allow: public="read"

The permission-group elements are instances of sf-token. The modes are instance of sf-string. There are two headers, which can be wrapped, so it must be possible to have those two fold into one header:

WAC-Allow: user="read write", public="read"

That key-value pair, where the keys are unique, indicates that we have an sfDictionary and indeed if I can parse it that way getting

ListMap(Token(user) -> PItem(SfString(read write),ListMap()), Token(public) -> PItem(SfString(read),ListMap()))

Instead of having a string of concatenated values one could use the Inner List structure of RFC8941 and so have headers like this:

WAC-Allow: user=("read" "write"), public=("read")

And that indeed parses to

ListMap(Token(user) -> IList(List(PItem(SfString(read),ListMap()), PItem(SfString(write),ListMap())),ListMap()), Token(public) -> IList(List(PItem(SfString(read),ListMap())),ListMap()))

The empty ListMap() just indicate that there are no attributes on the "read" or "write" sfStrings and no attributes on the IList either.

I am not sure if there is much gained by having the modes be strings. They could just as well be sf-tokens. In which case we would have

WAC-Allow: user=(read write), public=(read)

which parses to

ListMap(Token(user) -> IList(List(PItem(Token(read),ListMap()), PItem(Token(write),ListMap())),ListMap()), Token(public) -> IList(List(PItem(Token(read),ListMap())),ListMap()))

The output generated by the parser looks verbose, but it the implementations is reasonably efficient.

[bblfish]

I have added the three examples above to my test suite

[bblfish]

I have moved my implementation of the RFC8941 parser to it's own project in the httpSig repo.
It is write-in Scala and compiles to the JVM and to JS. (still working on pieces there).