You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems like a significant addition that should be mentioned.
Associated with this is a change to net/http/httptest.ResponseRecorder
that ended up breaking our tests because for historical reasons
we were constructing the ResponseRecorder directly with the HeaderMap
field, expecting that that be reflected in result of the Header method,
but that's no longer the case.
It was an easy fix and we shouldn't have been doing that anyway, but
a reminder that it's easy to break things even when keeping the
exposed API ostensibly the same.
The text was updated successfully, but these errors were encountered:
I'm guessing the change is c69e686 but that isn't in Go 1.6.
Before that change it was possible for the handler to access the values in the (previously set) HeaderMap. Should we re-enable this use case? @bradfitz
I'm sorry - I hadn't noticed the Trailer stuff before and a brief git blame
made me think it was new. c69e686 is indeed the change I'm talking
about, and yes, it's not in Go 1.6. It did break our tests, but it's
arguable whether that's a problem (FWIW we were creating the
ResponseRecorder directly to remain backwardly compatible with an old
API that used it, even though we changed all our tests to use httptest.NewServer
instead for better correspondence of tests to real world behaviour).
bradfitz
changed the title
doc: Go 1.6 release notes don't mention Trailer support in net/http
net/http/httptest: something about the ResponseRecorder change
Mar 26, 2016
This seems like a significant addition that should be mentioned.
Associated with this is a change to net/http/httptest.ResponseRecorder
that ended up breaking our tests because for historical reasons
we were constructing the ResponseRecorder directly with the HeaderMap
field, expecting that that be reflected in result of the Header method,
but that's no longer the case.
It was an easy fix and we shouldn't have been doing that anyway, but
a reminder that it's easy to break things even when keeping the
exposed API ostensibly the same.
The text was updated successfully, but these errors were encountered: