Capitalisation questions

[edent]

As per https://github.com/gabboman/wafrn-backend/issues/16 - I received a set of HTTP headers like:

Host:  example.viii.fi
Date:  Sun, 25 Feb 2024 14:53:21 GMT
Digest:  SHA-256=9akxEYDP5jC6qHvCHScxcd7zNgpkx9QTZWRsLyjHLzE=
signature:  keyId="https://app.wafrn.net/fediverse/blog/catpawsmeowmeow#main-key",algorithm="rsa-sha256",headers="(request-target) host date algorithm digest",signature="jorLnAs7phN564FE02geQS/d276TVhPn0V+cqfOHDgMklADz9PaUhGinGJmsVd4Rh9muid9hBsJIrdkbXtCMC+EHR/..="
Content-Length:  1398

My code was unable to find the signature because it was expecting a Title-Case Signature. It appears that the convention (although not the spec) is to use Title-Case rather than lower case.

However, within the signature, I see headers="(request-target) host date algorithm digest". This is confusing because my code tokenises the headers and then looks for those tokens in the HTTP header. As you can see, there are no HTTP headers called host or date or digest.

I think it would be useful to have some clarification on where case-sensitivity is may be encountered and what developers can do to prevent errors.

[nightpool]

Hi, this isn't part of the HTTP Signature spec per se, but it's actually defined by the HTTP specification. See RFC 9110 5.1 Field Names (https://datatracker.ietf.org/doc/html/rfc9110#name-field-names):

Field names are case-insensitive and ought to be registered within the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see Section 16.3.1.

This has been part of the HTTP specification since version 1.1 and it's much more common with the advent of HTTP/2, which further restricts HTTP/1.1 and I believe only allows lowercase field names to be transported. If your HTTP library does not support case insensitive field names (the recommended guidance is to transform all header names to lowercase when processing them), then I suggest you update your library or file a bug.

[nightpool]

Yes, here we go, the HTTP/2 spec says:

A field name MUST NOT contain characters in the ranges 0x00-0x20, 0x41-0x5a, or 0x7f-0xff (all ranges inclusive). This specifically excludes all non-visible ASCII characters, ASCII SP (0x20), and uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a). ... Note: An implementation that validates fields according to the definitions in Sections 5.1 and 5.5 of [HTTP] only needs an additional check that field names do not include uppercase characters.

[edent]

Yes, I know. I think that if you're documenting how signatures work then it would be good to be explicit about how they work in practise.

[snarfed]

Incorporated into #33.