undef1nd / sfv Goto Github PK

I feel pretty dumb asking this.

So I want to use the crate to help me handle Extensible Priorities headers, which is a set of priority parameters encoded as a Structured Headers Dictionary.

So far we have defined two parameters, u is an sh-integer, and i is a sh-boolean. When I parse this I want to ensure that the parameters are the expected type.

Take this example

fn main() {
    let ext_priority = "u=2,i";
    let dict = Parser::parse_dictionary(ext_priority.as_bytes());
    assert!(dict.is_ok());
    println!("{:#?}", dict);
}

prints:

Ok(
    {
        "u": Item(
            Item {
                bare_item: Integer(
                    2,
                ),
                params: {},
            },
        ),
        "i": Item(
            Item {
                bare_item: Boolean(
                    true,
                ),
                params: {},
            },
        ),
    },
)

great, it works!

But if I modify the input slightly to change the contents of u

fn main() {
    let ext_priority = "u=ohnoibrokeit,i";
    let dict = Parser::parse_dictionary(ext_priority.as_bytes());
    assert!(dict.is_ok());
    println!("{:#?}", dict);
}

prints:

Ok(
    {
        "u": Item(
            Item {
                bare_item: Token(
                    "ohnoibrokeit",
                ),
                params: {},
            },
        ),
        "i": Item(
            Item {
                bare_item: Boolean(
                    true,
                ),
                params: {},
            },
        ),
    },
)

The parser reads this as sh-token, not sh-integer.

How can I do some basic type checking of the parsing result?

sfv implements parsing validation, per the rules in RFC 8941. For example, Tokens are checked for valid character usage in https://github.com/undef1nd/sfv/blob/master/src/parser.rs#L290

However, I might have missed it but there doesn't appear to be an equivalent validation in the library when constructing such items. It seems like it would be helpful to support this, without having to resort to construction, serialization, and parsing.

For instance, the backing type to Token is String. And the docs suggest that I could create an Item of type Token by using

let token = BareItem::Token("12345");

This would strictly be an invalid token according to https://www.rfc-editor.org/rfc/rfc8941.html#section-3.3.4-7 - the first character is required to be either ALPHA or "*"

Of course, we could require that implementations sanitize their own values before passing into sfv. But then, sfv already implements the checks, just they aren't exposed in an easy way. It would be great to expose them for reuse.

The use case here is applications that pass through values from other things. If the receiving endpoint fails to parse that it will cause interop issues. It would be muc better if the sender had an opportunity to validate things before sending them, so that it might take mitigating action. There are probably still cases where a sender doesn't care, so perhaps checked and unchecked variants are required.

The LICENSE file contains the Mozilla Public License 2.0 while in Cargo.toml the license is given as "MIT/Apache-2.0".

Guide for license field: https://doc.rust-lang.org/cargo/reference/manifest.html?highlight=license#the-license-and-license-file-fields I assume MPL was the intended license, then MPL-2.0 is the correct value for this field.

I heard that this crate was used in Firefox and so I wondered if there are bindings to C or C++.

Maybe worth making parameters in Item and InnerList an Option<Parameters>?

Add examples of how to use Item/List/Dict members.

See discussion #76

serde_cbor is unmaintained

The serde_cbor crate is unmaintained. The author has archived the github repository.

Alternatives proposed by the author:

• ciborium
• minicbor

See advisory page for additional details.

The old link https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html doesn't work anymore, so it should be updated to https://www.rfc-editor.org/rfc/rfc8941.html and text should no longer say "IETF draft"

• About text on Github
• Cargo.toml
• README.md
• lib.rs docstring

I can update the source code.