Skip to content
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

Implement accept header parsing? #4

Closed
glasser opened this issue Aug 25, 2022 · 7 comments
Closed

Implement accept header parsing? #4

glasser opened this issue Aug 25, 2022 · 7 comments

Comments

@glasser
Copy link

glasser commented Aug 25, 2022

There doesn't seem to be a great Rust implementation of accept header parsing. Accept headers are basically a comma-separated list of media types, and so you'd think you can just split on comma and then parse each piece with a library like your library or the mime library.

But commas can exist inside quoted parameters, so this is technically incorrect.

There are several common implementations that get this wrong. It would be great if a library could just solve this once and for all, and since mime seems to be unmaintained, maybe your library could be that place?

@picoHz
Copy link
Owner

picoHz commented Aug 26, 2022

@glasser Thanks for your nice proposal!
I just added MediaTypeList.

@glasser
Copy link
Author

glasser commented Aug 26, 2022

@picoHz Thank you!

If you want to be really picking, quoted-strings do have a backslash-escaping mechanism which can escape double quotes: https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6
But, say, the most popular npm Accept parser doesn't honor them either... presumably they are not common in practice.

@picoHz
Copy link
Owner

picoHz commented Aug 26, 2022

@glasser It's a good point. Backslash-escaping has been supported as of v0.19.8.

@picoHz picoHz closed this as completed Aug 28, 2022
@maxcountryman
Copy link

@picoHz is it intentional that MediaTypeList does not do any sorting of MediaType based on implicit and explicit q parameters?

My expectation is that any implicit items remain in provided order and any explicit items are reordered in accordance with their relative q parameters.

For example, this would order audio/basic as the first item and then audio/* as the second:

Accept: audio/*; q=0.2, audio/basic

@picoHz
Copy link
Owner

picoHz commented Apr 25, 2024

@maxcountryman MediaTypeList is implemented as an iterator so the order cannot be changed.

@maxcountryman
Copy link

@picoHz is this meant to parse Accept in accordance with the spec? My read of the first comment here is that was the hope at least.

Without q parameter precedence ordering, I think this would fall short of what's required by the RFC.

@maxcountryman
Copy link

Without input from @picoHz it's unclear what the intent here is but regardless I've put together a parser for Accept that leverages this crate and implements headers::Header. Perhaps some folks here might find it useful. It's worth pointing out that there's some unfortunate duplication as the inner workings of MediaTypeList need to be adapted for MediaTypeBuf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants