Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content-Type should not be sniffed for HEAD requests #2885

Closed
patrickmn opened this issue Feb 6, 2012 · 3 comments
Closed

Content-Type should not be sniffed for HEAD requests #2885

patrickmn opened this issue Feb 6, 2012 · 3 comments
Milestone

Comments

@patrickmn
Copy link

afa99ad294e7+ tip

From RFC 2616:

9.4 HEAD

   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. This method is
   often used for testing hypertext links for validity, accessibility,
   and recent modification.

14.17 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.

Since it SHOULD be identical to the GET request, it is not mandatory--and it seems
unnecessary to read the body to infer the content-type just for HEAD requests--but we
should not be returning an incorrect Content-Type (text/plain) for HEAD requests for
e.g. mp3, html files.
@patrickmn
Copy link
Author

Comment 1:

CL: http://golang.org/cl/5633045

@dsymonds
Copy link
Contributor

dsymonds commented Feb 6, 2012

Comment 2:

Labels changed: added priority-go1, packagechange, removed priority-triage.

Status changed to Started.

@dsymonds
Copy link
Contributor

dsymonds commented Feb 6, 2012

Comment 3:

This issue was closed by revision fb86bbe.

Status changed to Fixed.

@rsc rsc added this to the Go1 milestone Apr 10, 2015
@rsc rsc removed the priority-go1 label Apr 10, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants