#13922 closed bug (fixed)
HEAD responses with application/json results parseerror
Reported by: | Owned by: | jaubourg | |
---|---|---|---|
Priority: | blocker | Milestone: | 1.10 |
Component: | ajax | Version: | 1.9.1 |
Keywords: | Cc: | jaubourg | |
Blocked by: | Blocking: |
Description
Using ajax to fetch an URL using request type HEAD leads to parseerror when content-type is application/json on response. Using GET, it worked as expected.
According to RF2616, section 10.2.1 "HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body". When the type of request is HEAD, jQuery should accept empty response, even when content-type is defined as application/json.
This fails $.ajax({
url : "http://ip.jsontest.com/", type : "HEAD", success : function() { console.log("HEAD OK!"); }, error : function() { console.error("HEAD Failed!"); }
});
This is ok $.ajax({
url : "http://ip.jsontest.com/", type : "GET", success : function() { console.log("GET OK!"); }, error : function() { console.error("GET Failed!"); }
});
Change History (5)
comment:1 Changed 10 years ago by
Cc: | jaubourg added |
---|
comment:2 Changed 10 years ago by
(Well, it's tempting to special case HEAD requests here but isn't the fact the server delivers a response to a HEAD request with an actual content-type the real issue here ? If there is not content, why is the server providing a content-type ?)
Scrap that, this IS a bug. The HEAD request is supposed to have the same headers as the GET request. It's getting late here ;)
comment:3 Changed 10 years ago by
Component: | unfiled → ajax |
---|---|
Owner: | set to jaubourg |
Priority: | undecided → blocker |
Status: | new → assigned |
comment:4 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Handles HEAD requests as if they always were 204. Fixes #13922.
Changeset: a2cd89a795067d67d8212a4571991e5d2fb0ea8f
comment:5 Changed 10 years ago by
Milestone: | None → 1.10 |
---|
It does seem like we shouldn't be parsing content on HEAD requests since no data is ever expected. This is a bit different than #13450 where the browser sets a content-type but has a content-length of 0 for a request that should return data.