net/http: ResponseWriter panics in WriteHeaders that were formerly ignored

[rsc]

See comments on CL 80077.

I am worried about (accidental) sequences like:

w.Write([]byte("whatever"))
w.WriteHeader(badCode)

or

w.Hijack()
w.WriteHeader(badCode)

Those WriteHeader calls were formerly reported in a logf as out of sequence but otherwise ignored. They should probably continue to be logf+no-op instead of causing a panic.

[rsc]

It's also not obvious why mapping to a 500 or some other internal error wouldn't be better than panic.

[bradfitz]

See some discussion about this on #22880.

The point is to be consistent between HTTP/1 and HTTP/2. The hack we did for HTTP/1 was never right anyway, had no HTTP/2 analogue, and only hid real problems from users. (e.g. #22880 (comment))

People won't notice a 500. I'd like to keep the panic, at least for the betas and see if it trips up anybody whose code wasn't broken.

[bradfitz]

I'd be fine changing this to code 500 too as long as it's accompanied by stderr log spam so people can fix their code.

But I'd rather do that after a beta or two if it's actually necessary.

[gopherbot]

Change https://golang.org/cl/86255 mentions this issue: http2: don't check WriteHeader status if we've already sent the header

[gopherbot]

Change https://golang.org/cl/86275 mentions this issue: net/http: don't validate WriteHeader code if header's already been sent