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: record http header field order #21853

Closed
shanemhansen opened this issue Sep 12, 2017 · 4 comments

Comments

Projects
None yet
6 participants
@shanemhansen
Copy link
Contributor

commented Sep 12, 2017

I know this issue has been discussed before, but I'm not sure if this use case has been brought considered. In some cases it can be useful for a WAF to understand what the original header order of a request was. For example see this attempt to detect phantomjs browsers based on when the Host header appears. https://blog.shapesecurity.com/2015/01/22/detecting-phantomjs-based-visitors/

If go can record/model header order then go can more easily do WAF stuff and block bad requests going into an organization's network, arguably an enhancement in an area Go is already optimized for (network proxies).

I propose adding a attribute to http.Request called RawHeader which is a [][2]string.

I've ran a fork of go with this particular enhancement for a couple years, and my organization has found this feature useful.

See also #19292

@gopherbot gopherbot added this to the Proposal milestone Sep 12, 2017

@gopherbot gopherbot added the Proposal label Sep 12, 2017

@ianlancetaylor ianlancetaylor changed the title proposal: record http header field order proposal: net/http: record http header field order Sep 12, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2017

@tombergan

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2017

I doubt we will add a RawHeader field. At least, unlike #19292, there seems to be an actual use case, although narrow. Ideally this would be a dup of #18997.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 25, 2017

I agree that tracing is a better way to get this data, if at all. Putting anything new like this into Request bloats request and forces extra tracking and preparation for something that 99.99% of clients are never going to ask for. In contrast, tracing can be restricted to only the times when tracing is actually happening. It doesn't take up extra space in data structures or extra execution time the rest of the time. Going to mark close this. If you would like to interpret this as a dup of #18997, that's fine, although that issue doesn't seem close enough to a clear proposal to evaluate whether that's really true.

@rsc rsc closed this Sep 25, 2017

@qZanity

This comment has been minimized.

Copy link

commented Nov 8, 2017

@shanemhansen I don’t suppose you can send me your modified net/http source so I can implement too?

@golang golang locked and limited conversation to collaborators Nov 8, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.