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.

Sign up for GitHub

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

Jump to bottom

proposal: net/http: record http header field order #21853

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

proposal: net/http: record http header field order #21853

shanemhansen opened this issue Sep 12, 2017 · 4 comments
Labels
FrozenDueToAge Proposal
Milestone
Proposal

Comments

@shanemhansen
Copy link
Contributor

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
@ianlancetaylor ianlancetaylor changed the title proposal: record http header field order proposal: net/http: record http header field order Sep 12, 2017
@ianlancetaylor
Copy link
Contributor

CC @tombergan

@tombergan
Copy link
Contributor

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
Copy link
Contributor

rsc 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 as completed Sep 25, 2017
@qZanity
Copy link

qZanity commented Nov 8, 2017

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

@plambein plambein mentioned this issue Mar 13, 2018
Closed
@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.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
6 participants
@rsc @shanemhansen @ianlancetaylor @qZanity @gopherbot @tombergan