Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#7099 closed bug (worksforme)

AJAX does not correctly handle HTTP Responses that include content-type but do not have a message-body

Reported by: msutton Owned by:
Priority: undecided Milestone: 1.4.3
Component: ajax Version: 1.4.2
Keywords: ajax http status 204 Cc:
Blocked by: Blocking:


An example of this is the 204 No Content status. The HTTP specification is unclear as to the inclusion of content-type. It does not forbid including it at any rate. But it does forbid the inclusion of a message-body. If the content-type is something other than text/plain or not included, jQuery will attempt to parse the non-existent message-body and fail.

The behavior should be to disregard processing the message-body entirely for a response with status 204 an other status that don't have a message-body.

Change History (3)

comment:1 Changed 12 years ago by snover

Resolution: worksforme
Status: newclosed

I am not able to reproduce any issue with 204s and Content-Type. Please be aware that Internet Explorer returns a status code of 1223, not 204, so if you are specifically checking xhr.status, you will need to check for both.

If you can provide a link to a reproducible test case, please do so and we will reopen this ticket.

comment:2 Changed 12 years ago by [email protected]

Hi, I found the same current behavior, and came to the same conclusion: jQuery should ignore the content body if the response status is 204. I couldn't easily find a publicly available URL that returns a 204 response - access to our app is authenticated.

comment:3 Changed 12 years ago by [email protected]

I noticed by chance the requests like <http://video-stats.video.google.com/s?vid=ssRP5itpfNuiTbaVGANJWrSx0rtNxrJ9C4> yield responses w/ status 204, although they also include content-type headers. Anyway, try this jsFiddle page to reproduce: <http://jsfiddle.net/vqfzz/1/> -- the success handler doesn't fire. If you change the requested path to /echo/html, behavior reverts to expected (i.e. the success handler fires).

Note: See TracTickets for help on using tickets.