when use io.copy and fmt.Fprintf write to http.ResponseWriter, the Response's head is not the same
wachmc
func handler(w http.ResponseWriter, r *http.Request) {
rr := strings.NewReader("<body>hello</body>")
io.copy(w, rr)
}
the Response's head's Content-Type:text/plain;
but try this:
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "<body>hello</body>")
}
the Response's head's Content-Type:text/html;
what lead to the difference?
David Symonds
Sounds like a bug. Can you file it on the issue tracker?
Dave.
Sanjay Menakuru
Patrick Mylund Nielsen
wachmc
On Feb 5, 5:18 pm, Sanjay Menakuru <balasan...@gmail.com> wrote:
> I can't reproduce this... This is what I'm testing withhttp://play.golang.org/p/xi2czF7UDC on tip, and seems to give text/html
wachmc
but under firefox/chromium the result are text/plain and text/html...
On Feb 5, 5:26 pm, Patrick Mylund Nielsen <g...@patrickmylund.com>
wrote:
> tip (da15310087d6+), Linux x64:
>
> Date: Sun, 05 Feb 2012 09:22:27 GMT
> Content-Type: text/plain; charset=utf-8
>
Sanjay Menakuru
Sanjay Menakuru
Sanjay Menakuru
wachmc
wachmc
> functionhttp://tip.golang.org/src/pkg/net/http/sniff.go?s=576:618#L11, you
Patrick Mylund Nielsen
David Symonds
<g...@patrickmylund.com> wrote:
> One can argue if that's what it's supposed to be doing, though:
>
> RFC 2616: "The HEAD method is identical to GET except that the server MUST
> NOT return a message-body in the response. The metainformation contained in
> the HTTP headers in response to a HEAD request SHOULD be identical to the
> information sent in response to a GET request. This method can be used for
> obtaining metainformation about the entity implied by the request without
> transferring the entity-body itself."
>
> Should a HEAD request for an MP3 file really be returning Content-Type:
> text/plain?
"SHOULD" implies something to be done if it is feasible. In this case,
the sniffer cannot sniff an absent body, so the handler code needs to
explicitly w.Header().Set("Content-Type", "audio/mp3") or whatever.
So, yes, the server should be doing this, but it's not something that
the net/http can really help with.
Dave.
David Symonds
> So, yes, the server should be doing this, but it's not something that
> the net/http can really help with.
Actually, it could, if the handler always yields a body even for HEAD
requests. However, it's probably a good idea for HEAD-aware handlers
to start with something like
if req.Method == "HEAD" {
// set headers, etc.
return
}
because HEAD requests are meant to be lightweight, and copying a large
response body around is not lightweight.
Dave.
David Symonds
<g...@patrickmylund.com> wrote:
> It seems the RFC is pretty specific about Content-Type: "The Content-Type
> entity-header field indicates the media type of the entity-body sent to the
> recipient or, in the case of the HEAD method, the media type that would have
> been sent had the request been a GET."
>
> If you agree with the previous: http://codereview.appspot.com/5633045
That looks sensible to me. I'd put the "w.req.Method != "HEAD" check
on the outer if statement, and remove Content-Type from the filter
list (it's reasonable to set it for 304 responses too).
Dave.
Patrick Mylund Nielsen
Yeah. It seems silly to start reading the body just to infer the type for that header.Perhaps it would be less confusing if the Content-Type header just wasn't set (by default) for HEAD requests?