Bug Tracker

#7099 closed bug (worksforme)

Opened September 29, 2010 09:34PM UTC

Closed September 29, 2010 09:49PM UTC

Last modified October 25, 2010 08:50PM UTC

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:
Description

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.

Attachments (0)
Change History (3)

Changed September 29, 2010 09:49PM UTC by snover comment:1

resolution: → worksforme
status: new → closed

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.

Changed October 25, 2010 07:20PM UTC by erath@fmyi.com comment:2

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.

Changed October 25, 2010 08:50PM UTC by erath@fmyi.com comment:3

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