-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic parsing / serialization #42
Comments
I know this is a two-year-old issue, but wanted to point out that because of syntactical overlap between top-level structured headers types (List, Dictionary, Item), it might not be possible to parse a header generically. For example, consider the following example header (from http_sf):
Note Having said the above, in either case, the strict re-serialization of this header is identical,
so I'm not sure if this is a compelling example... 🤔 This issue is asking about normalizing structured field values (in a generic way) for the purposes of processing HTTP message signatures, so I assume it's related to handling the
The italicized portion seems to suggest that it's a prerequisite to know the type of the structured field in order to strictly re-serialize it. This is exactly what the JavaScript implementation of RFC 9421 (misskey-dev/node-http-message-signatures) does: Considering the above guidance from RFC 9421, would it ever be needed to re-serialize a structured field of an unknown type? (I would think not.) |
Problem description
When dealing with headers, it's hard for a generic library to know what the serialization for an arbitrary header is going to be.
If we wish to normalise an arbitrary header without knowing it's serialization (is it a dictionary, a list, or an item?) then to parse the header reliably becomes somewhat tedious.
Further to this, serialisation becomes tricky as well. Any parser that is implemented by this libary's consumer to attempt to parse the fields in a generic way must somehow keep hold of the type that was successfully parsed and, likewise, how to re-serialize it (if needed). Serializing the values of a dictionary are more complex still as there's no concrete way to know if the item in the Map is itself an
Item
or andInnerList
. (edit: there is anisInnerList
type guard which is useful for this purpose).The lack of concrete typing of the returned values from the parsers make inference harder as well. If the returned types were first-class classes that we could perform
instanceof
checks on or similar, then inferring the type once parsed in a generic manner would be easier, including the serialization of any sub items that were returned.Proposed solution
Implementing concrete classes would facilitate a more generic parsing / serialization approach to the data that an application deals with.
For example:
With this kind of concrete implementation we can then perform some more generic parsing/serialization of dictionaries.
Above the consumer doesn't need to know anything about the items in the dictionary to serialize them, we can also see that this could extend to a more generic parser that returns the appropriate class for the structured field, and then can be acted on appropriately.
The existing
parseDictionary()
and similar functions effectively become factories for the respective classes (mostly for backwards compatability) and then we could introduce a genericparseHeader()
/parseField()
function that could follow the guidance of the spec in terms of parsing structured fieldsUse case
I'm working on HTTP Message Signing, which requires parsing of structured headers in a generic way. It's not feasible for the signer/verifier logic to know exactly what type of structured header we (should) be parsing, there's also a need to be able to serialize headers or items in dictionaries, without having to know ahead of time what the type of item we are dealing with.
How does this sound as an approach?
The text was updated successfully, but these errors were encountered: