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

proposal: net/http: add support for the upcoming "Structured Field Values for HTTP" RFC #41046

Open
dunglas opened this issue Aug 26, 2020 · 8 comments · May be fixed by #41045
Open

proposal: net/http: add support for the upcoming "Structured Field Values for HTTP" RFC #41046

dunglas opened this issue Aug 26, 2020 · 8 comments · May be fixed by #41045
Labels
Projects
Milestone

Comments

@dunglas
Copy link
Contributor

@dunglas dunglas commented Aug 26, 2020

Structured Field Values for HTTP is an upcoming RFC from the HTTP Wording Group defining a set of well-defined data types to use in HTTP headers and trailers.

This new format will improve the interoperability and the safety of HTTP by allowing to create generic parsers and serializers suitable for all HTTP headers. It is already used in the wild, for instance for the new security headers supported by Google Chrome (Sec-Fetch-Dest etc), the Signature proposal in Prefer-Push or in Vulcain.

After the RFC publication, it would be nice to be able to parse and generate such headers directly using the standard library.

I proposed a patch adding support for this spec in #41045. The code is also available as a standalone library: https://github.com/dunglas/httpsfv

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 26, 2020

Change https://golang.org/cl/250837 mentions this issue: net/http: add a package to parse and serialize Structured Field Values

@bradfitz bradfitz changed the title Add support for the upcoming "Structured Field Values for HTTP" RFC proposal: add support for the upcoming "Structured Field Values for HTTP" RFC Aug 26, 2020
@gopherbot gopherbot added this to the Proposal milestone Aug 26, 2020
@gopherbot gopherbot added the Proposal label Aug 26, 2020
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 26, 2020

I think this is probably best outside the standard library until the RFC is accepted. Once it's in the standard library it's pretty frozen and we can't change APIs or break behavior easily.

@dunglas
Copy link
Contributor Author

@dunglas dunglas commented Aug 26, 2020

For sure!

@ianlancetaylor ianlancetaylor changed the title proposal: add support for the upcoming "Structured Field Values for HTTP" RFC proposal: net/http: add support for the upcoming "Structured Field Values for HTTP" RFC Aug 26, 2020
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Aug 26, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Aug 28, 2020

@dunglas, your README has a broken link. Should be https://pkg.go.dev/github.com/dunglas/httpsfv.

@rsc
Copy link
Contributor

@rsc rsc commented Aug 28, 2020

Also, given your comment above (For sure!) it sounds like you are saying to close this proposal until at least the RFC is accepted?

@dunglas
Copy link
Contributor Author

@dunglas dunglas commented Aug 29, 2020

@rsc thanks, link fixed.

We should at least wait for the Internet-Draft to become a RFC before merging the patch related to this proposal. However, it should happen soon. The specification is in last stages of standardization. The algorithms described in the I-D and implemented in the patch will most likely not change anymore.

The proposal can probably be kept open, and we can use the time window before the publication as a RFC to review and improve the patch.

@rsc
Copy link
Contributor

@rsc rsc commented Sep 2, 2020

@dunglas, I looked at at httpsfv and my first thought is: can we make this simpler? It seems like a huge amount of new API surface for HTTP.

@dunglas
Copy link
Contributor Author

@dunglas dunglas commented Sep 2, 2020

@rsc we can maybe reduce the API surface a bit, but probably not much. The spec defines many data structures, and several of them cannot be implemented using only Go's builtins: https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#types

The main difference is that SFV's maps (Dictionary and Params) are ordered while Go's map isn't. Much of the API surface is related to these two types and the related methods. We can maybe remove the Del() methods from them, but I'm not sure if it's worth it (having the ability to remove elements from maps is convenient in some cases).

Another option would be to use interface{} in most places. This would allow to merge all Unmarshal* methods and maybe to also merge Dictionary and Params, but it will make the library less safe and less practical to use.

However I may have missed opportunities to reduce the API surface. I'm open to any suggestion to simplify this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.