1

I like the ability to present a buffered net/http.ResponseWriter as a net/http.Response in some situations which net/http/httptest.ResponseRecorder would give me, but the package name makes me a bit concerned about using it in production code. I understand that it’s intended to be used primarily for testing, but am unsure if I am asking for trouble using it in production code.

Am I tempting fate?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Loren Osborn
  • 131
  • 6
  • Why do you need present the data as an `http.Response`? Is it sufficient to provide status, headers written by the application and body as a []byte? – Charlie Tumahai Oct 15 '18 at 16:37

1 Answers1

3

You should not use this code in production. No matter what you are attempting to achieve.

httptest.ResponseRecorder's ultimate purpose is to facilitate testing, and will thus always be extended, optimized—rewritten—with testing in mind. Any assumption can be made in this package, as long as it makes the package better at testing. The package authors intended for this to be "used in concert with go test"¹. I interpret that as discouraging production use, because they are then free to break e.g. your production usage in favor of go test usage.

Another argument is that of security. The security model of any test package is going to be that the usage is trusted, whereas non-testing code will be the opposite.

The world of software a perilous place. You are asking to make it even more perilous.

Jonas G. Drange
  • 8,749
  • 2
  • 27
  • 38
  • `httptest.ResponseRecorder` -- its purpose is to record responses. If you cannot rely on the "to record responses" for production use, how can you rely on it for testing then? – zerkms Oct 15 '18 at 07:08
  • You can't compare production and testing like that. In testing, _I_ write the inputs, in production we must assume _anyone_ (including malignant actors) can write the inputs. – Jonas G. Drange Oct 15 '18 at 08:31
  • 3
    I see that you added the security point, which I partially agree with. Yet I still fail to see how "it's unreliable" point makes any sense: it must be reliable, be it for test or production. "All production usage of the package is disregarded by its authors" --- any source for that? – zerkms Oct 15 '18 at 08:48
  • 1
    From [1](https://golang.org/pkg/testing/): "\[the test package\] is intended to be used in concert with the 'go test' command". I.e. it is the intention of the authors to be used in testing. I can moderate my answer, since that's strongly worded here. – Jonas G. Drange Oct 15 '18 at 09:39
  • But the test package is not the httptest package! And which part of the implementation could have security issues? The recorder uses a bytes.Buffer, so why is this an issue? – apxp Oct 15 '18 at 11:41
  • This is definitely an angle I hadn’t considered. I need to “sit with this answer a bit” before marking it “accepted”, but this does sound like what my gut concern was. I think you captured it quite well. Thank you. – Loren Osborn Oct 15 '18 at 12:18
  • @apxp you're right. That's a bit confusing. Feel free to remove that from the answer. I am at the moment equating the test and httptest package. – Jonas G. Drange Oct 15 '18 at 12:29