Why is http.Error setting Content-Type to plain/text?

[Bjorn Tipling]

Hi,

http.Error sets Content-Type to plain/text.[1] The very next thing it does is call WriteHeader making it impossible to use http.Error with a pretty HTML template. Why would serving an HTTP error mean that it would also have to be a plain/text Content-Type? It does not say anything about this in the RFC [2]. This also makes building a Restful JSON API in an idiomatic way using the net/http package difficult as well since you cannot have a Content-Type for application/json and use http.Error. http.NotFound uses Error, so that is also being served via plain/text. 

Sure I could just write my own Error, and my own NotFound, but that does not make sense to me. It is just http.Error, I should be able to use it even if my error is not being sent in plain/text. 

[1] http://golang.org/src/pkg/net/http/server.go?s=20053:20105#L686

[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1

[David Symonds]

http.Error is a three-line helper function for the very common case of
returning an error code with a simple message. If you want something
different, you can write your own, like you said.


Dave.

[Jimmy Zelinskie]

I believe that this could easily be accomplished without overwriting the content-type. Removing that line would give the function just a little more added utility.

I'm sure most browsers could probably deduce that it's plaintext without the header.

[Bjorn Tipling]

> http.Error is a three-line helper function for the very common case of 
returning an error code with a simple message. If you want something 
different, you can write your own, like you said. 

Of course I have written my own error and not found handlers now, because the one in the net/http package not useful.

I can't think of any websites that show only plain/text errors and not found responses. It isn't that common at all. The quality of this package can be improved by removing the one line where it sets the Content-Type, or perhaps it could take an optional string as an argument for Content-Type.

Just a suggestion. It would be an improvement.