Note: There are a few cases of duplicates in user autocompletion which are being worked on.

nsIXMLHttpRequest throws exception on access of status member when the request failed due to a timeout

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
XML
RESOLVED FIXED
12 years ago
11 months ago

People

(Reporter: Willem Joosten, Assigned: bz)

Tracking

Trunk
mozilla1.9alpha1
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

When a request is done using xmlhttprequest the callback is called with a
request status going from 1 to 4 (finished) When the called server times out on
the call status 4 is reached but accessing the status property produces this
exception:

Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111
(NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
http://freeby/ajax/v2/formdemo.js :: handleAddressSaved :: line 192"  data: no]
Source File: http://freeby/ajax/v2/formdemo.js
Line: 192

This happens in 'alert(req.status)' as wel as testing for the existince of the
property using if(req.status)

This happens both in the Firefox version above as well as version 0.9 on FreeBSD
4.10.

Reproducible: Always

Steps to Reproduce:
1. create a XMLHttpRequest
2. make the server timeout (in Apache change the line 'TimeOut 300' in the
config file to something smaller
3. try to access the status property of the request object 

Actual Results:  
Javascript throws an exception.

Expected Results:  
The status en statusText property should be defined, maybe with a undefined value.
(Reporter)

Comment 1

12 years ago
The status also can't be read when the server is not reachable. Also the
readyState goes through status 2 (statusLoaded) and 3 (statusInteractive) before
reaching 4.
Depends on: 238559

Comment 2

12 years ago
I am experiencing the same phenomenon.  A workaround is to catch the exception,
although the exception should not have been thrown, as request.readyState should
not have had a value of 4.

Comment 3

12 years ago
This bug still occurs in FireFox 1.5 Beta 1.

Updated

12 years ago
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Version: unspecified → 1.8 Branch

Comment 4

12 years ago
Still happens on FF1.7 when the server is terminated before the request is sent. A status field like this needs to handle this situation.
(Assignee)

Comment 5

12 years ago
Created attachment 204399 [details] [diff] [review]
Possible fix

We can't return "undefined" for an integer, but we can do the same thing as for a non-HTTP request -- return 0.
Attachment #204399 - Flags: superreview?(jst)
Attachment #204399 - Flags: review?(darin)
(Assignee)

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.8 Branch → Trunk

Comment 6

12 years ago
Comment on attachment 204399 [details] [diff] [review]
Possible fix

r=darin

Please document this in nsIXMLHttpRequest.  Is this documented in the Web Apps spec?  Should it be?  What do other browsers do?
Attachment #204399 - Flags: review?(darin) → review+
(Assignee)

Comment 7

12 years ago
Comment on attachment 204399 [details] [diff] [review]
Possible fix

Per conversation with hixie, something like a 5xx code would make more sense here...

Stephen, Gabriel, Willem, what status code does IE return in this case?
Attachment #204399 - Flags: superreview?(jst) → superreview-
(Assignee)

Updated

12 years ago
Assignee: xml → bzbarsky
Target Milestone: --- → mozilla1.9alpha

Comment 8

12 years ago
> Per conversation with hixie, something like a 5xx code would make more sense
> here...

Really?  5xx seems to implicate the server, but that's not accurate.  Also, don't we need to worry about changing the API in an incompatible way?  What should the status codes be for 'file:' URLs?
(Assignee)

Comment 9

12 years ago
I'd be aiming to not change anything for file: urls -- those would continue to return 0.

502 doesn't necessarily implicate the server you were trying to contact...  Unfortunately, all the HTTP status codes do assume the server was contacted; none of them really mean "server didn't respond".  502 is the closest.

Comment 10

12 years ago
> I'd be aiming to not change anything for file: urls -- those would continue to
> return 0.

OK


> 502 doesn't necessarily implicate the server you were trying to contact... 
> Unfortunately, all the HTTP status codes do assume the server was contacted;
> none of them really mean "server didn't respond".  502 is the closest.

502 means there was a bad gateway.  That doesn't really sound accurate to me.

The first sentence of section 10.5 says:

  "Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request."

That really doesn't describe the case of a server response that is still pending.
(Assignee)

Comment 11

12 years ago
For still pending we want to keep throwing.  I think we should only change behavior for cases where our readyState is 3 or 4 (which means either OnDataAvailable or OnStopRequest has been called).  But network timeout will call OnStopRequest, as will connection refused, etc, right?
onStopRequest will always be called if asyncOpen returned success. so, yes.
(Assignee)

Comment 13

12 years ago
Created attachment 205440 [details] [diff] [review]
Updated patch

This makes sure we still throw if readyState is not 3 or 4 (so if we're still waiting on initial server response).  I sort of randomly decided that the generic 500 status code is good enough here, but I really don't care that much what we make it.  IE uses 12029, which is ERROR_INTERNET_CANNOT_CONNECT (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/wininet_errors.asp).  I don't really think we want to be following IE to the extent of using that status code; if we do decide to go that way, we should use whatever error status our OnStopRequest got.... ;)
Attachment #204399 - Attachment is obsolete: true
Attachment #205440 - Flags: superreview?(jst)
Attachment #205440 - Flags: review?(darin)
Comment on attachment 205440 [details] [diff] [review]
Updated patch

sr=jst
Attachment #205440 - Flags: superreview?(jst) → superreview+

Comment 15

12 years ago
>  I don't really think we want to be following IE to the extent of using that
> status code; if we do decide to go that way, we should use whatever error
> status our OnStopRequest got.... ;)

Perhaps an internal error code would be more useful than a made-up 500 response that looks like it came from the server.  Synthesizing a 500 response is bound to confound someone, who may end up blaming the server for the wrong thing, look in the server logs, wonder why the server logs show no 500 response, and so on...
(Assignee)

Comment 16

12 years ago
I could just return NS_ERROR_NOT_AVAILABLE as the int, sure.  Want me to?
(Assignee)

Comment 17

12 years ago
The problem there is whether WHATWG can interoperably specify this.  It seems like that would be desirable, but with NS_ERROR_NOT_AVAILABLE it's tough.

Comment 18

12 years ago
A WG could easily just say that the useragent will throw an error and not specify the error, right?
(Assignee)

Comment 19

12 years ago
But we're not throwing an error.  We're returning an integer.  The error case we're going to throw NOT_AVAILABLE and be done with it; the problem is the non-error case.

Comment 20

12 years ago
I think we should consider doing what IE does.... looks like we haven't figured that out yet.  Do we have a testcase?  Probably not, right?...  because it is difficult to simulate a network timeout?
(Assignee)

Comment 21

12 years ago
Hixie wrote a testcase for this, actually, so we do know exactly what IE does.  See comment 13 -- it returns an "HTTP status" of 12029, which corresponds to a WinAPI status code.

Comment 22

12 years ago
Sorry, I missed that while scrolling back through the comments.  So, do you really think that faking a legit server response code is the best solution here?  It doesn't feel right to me... perhaps we should have our own internal status code as well.  Otherwise, we are overloading the meaning of the HTTP 5xx status codes.
(Assignee)

Comment 23

12 years ago
Yeah, I have to admit that 500 does make me somewhat unhappy... ;)

Our internal status code would be NS_ERROR_NOT_AVAILABLE, I guess.

Comment 24

12 years ago
Yes, let's just return that then.  I think that's more reasonable.
(Assignee)

Comment 25

12 years ago
Created attachment 209107 [details] [diff] [review]
Updated to comments
Attachment #205440 - Attachment is obsolete: true
Attachment #209107 - Flags: review?(darin)
Attachment #205440 - Flags: review?(darin)

Updated

12 years ago
Attachment #209107 - Flags: review?(darin) → review+
(Assignee)

Comment 26

12 years ago
Fixed.  If someone feels a need for this to land on the 1.8 branch (so for Firefox 2), please request approval.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Duplicate of this bug: 366930

Comment 28

11 years ago
The specification http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 currently says that you have to set all members of the object to their initial values (excluding readyState). If you want this to change, by setting status to 500 for instance you should probably raise this on public-webapi.
(Assignee)

Comment 29

11 years ago
I don't think we really care so much what we return here.  I'm happy to return 0, as the spec would require.

We're going to need so many changes to implement that spec that it'll be more or less a wholesale rewrite of this file, though.  I figure once the spec is in CR and there are tests (so we can test said rewrite) we'll file a bug to implement that spec.

Comment 30

11 years ago
Ah, thanks for the heads up!
Blocks: 480200
You need to log in before you can comment on or make changes to this bug.