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

net/http/httptest: Better document usage of ResponseRecorder.HeaderMap vs. ResponseRecorder.Result #16717

Closed
cespare opened this issue Aug 16, 2016 · 2 comments
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@cespare
Copy link
Contributor

cespare commented Aug 16, 2016

The Go 1.7 release notes say:

The ResponseRecorder's new Result method returns the recorded http.Response. Tests that need to check the response's headers or trailers should call Result and inspect the response fields instead of accessing ResponseRecorder's HeaderMap directly.

However, the documentation itself doesn't give much guidance. The closest it says is

The Response.Header is a snapshot of the headers at the time of the first write call, or at the time of this call, if the handler never did a write.

If I were just reading the httptest docs, I would probably just use HeaderMap as it's more convenient. It would be good to put a caveat by the definition of HeaderMap.

@cespare
Copy link
Contributor Author

cespare commented Aug 16, 2016

/cc @bradfitz

@bradfitz bradfitz added this to the Go1.8 milestone Aug 16, 2016
@bradfitz bradfitz self-assigned this Aug 16, 2016
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 7, 2016
@gopherbot
Copy link

CL https://golang.org/cl/32190 mentions this issue.

@golang golang locked and limited conversation to collaborators Oct 26, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants