An important thing with it is to support everything; for headers, for example, unsupported ones are of the enum variant `ExtensionHeader(~str, ~str)`, and with methods there's the `ExtensionMethod(~str)`.

Taking your example of the Authorization header: that uses the `credentials` type, defined in RFC 2617 (https://tools.ietf.org/html/rfc2617), which ends up thus:

      auth-scheme    = token
      auth-param     = token "=" ( token | quoted-string )
      credentials = auth-scheme #auth-param

That could be supported something like this:

    struct Credentials {
        scheme: ~str,
        parameters: ~[(~str, ~str)],
    }

But then, Basic and Digest come into the mix, and they've got data that should be treated as data rather than text. I'll probably end up with renaming the struct above to ExtensionCredentials (oh no! it doesn't have a proper name!) and using an enum:

    enum Credentials {
        BasicCredentials(BasicCredentials),  // A new struct
        DigestCredentials(DigestCredentials),  // Ditto
        ExtensionCredentials(ExtensionCredentials),
    }

I've been playing in my mind with having traits to convert such things as custom credentials in some way without you needing to maintain it yourself in your own place, but it's not an easy problem however you dice it.

In the end, it is all about balance, as you say, and I'm not sure precisely where the balance falls, yet. But I know it uses the type system a whole lot more than almost all of the code that's out there.