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
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
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).
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
An example of such a header would be:
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: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
Instead of having a string of concatenated values one could use the Inner List structure of RFC8941 and so have headers like this:
And that indeed parses to
The empty
ListMap()
just indicate that there are no attributes on the "read" or "write"sfString
s and no attributes on theIList
either.I am not sure if there is much gained by having the modes be strings. They could just as well be
sf-token
s. In which case we would havewhich parses to
The output generated by the parser looks verbose, but it the implementations is reasonably efficient.