Basically it boils down to, is there any case where it would be bad for me to call the success callback function on status codes under 400?
In looking at the list of status codes for HTTP, I don't think there would be but I want to make sure. I don't think I'll be getting 1XX level codes as they look like most of them return before the full request is processed and readyState === 4
(I don't care about IE 7's 122). And I want to still return success on a 302 and 304 status codes. So is status < 400
an acceptable way to catch all of this?
Building on @sarnold's concerns, it looks like the XMLHttpRequest
specifications say the following:
If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security or infinite loop precautions). Any other error (including a 401) MUST cause the object to use that error page as the response.
Which seems to indicate to me that either 2XX or 3XX responses are valid. So, in short, my findings indicate status < 400
is an appropriate status response check.
A 301
means the client is responsible for making the HTTP call again with the new URL. Does your library or toolkit already handle this for you?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With