I’m having the same problem as you and think I have some idea about what’s happening but not the cause.

Your failed request includes a “Authorization: NTLM …” line and I’ll be that the payload of your request never made it to the server. If you aren’t sending anything with the send() method, then you’re probably not noticing it.

I believe that the browser is attempting to send a request to authenticate the request before it actually bothers to post the data your requesting.

At least that’s what I’m seeing in my code when I look at it with Fiddler.

Still haven’t figured this one out yet and it’s quite puzzling (especially since Microsoft’s AJAX libraries with ASP.NET AJAX work fine…).

The odd thing is that it all works fine if I’m running Fiddler (which kind of makes me wonder whether it’s a caching issue). As soon as I shut off Fiddler, I get 400/”Bad Request” errors.

In order to inspect the HTTP request, I had to use WireShark on the server (since Fiddler on the client was causing it to work for every request). It turns out that the requests are drastically different on successful attempts and failed attempts. Notably, even though the requests are identical, the content length is always 0 on failed requests.

Here is a failed request:


POST /FirstPoint.Common.Services.UserDriven/UserDrivenService/GetRoutes HTTP/1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Language: en-us
x-prototype-version: 1.6.0.2
Referer: http://zorch6:2345/_layouts/FirstPointUserDrivenRoutes/Default.aspx
x-requested-with: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2; MS-RTC LM 8; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: zorch6:2345
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: MSOWebPartPage_AnonymousAccessCookie=2345; WSS_KeepSessionAuthenticated=2345; previousLoggedInAs=; loginAsDifferentAttemptCount=
Authorization: NTLM TlRMTVNTUAABAAAAB7IIogkACQA0AAAADAAMACgAAAAFAs4OAAAAD0NIQVJMRVMtUVVBRFdPUktHUk9VUA==

Here is a successful request:

POST /FirstPoint.Common.Services.UserDriven/UserDrivenService/GetRoutes HTTP/1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Language: en-us
x-prototype-version: 1.6.0.2
Referer: http://zorch6:2345/_layouts/FirstPointUserDrivenRoutes/Default.aspx
x-requested-with: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2; MS-RTC LM 8; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: zorch6:2345
Content-Length: 16
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: MSOWebPartPage_AnonymousAccessCookie=2345; WSS_KeepSessionAuthenticated=2345; previousLoggedInAs=; loginAsDifferentAttemptCount=

And here is a request from FF (in which the AJAX request works flawlessly):

POST /FirstPoint.Common.Services.UserDriven/UserDrivenService/GetRoutes HTTP/1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Language: en-us
x-prototype-version: 1.6.0.2
Referer: http://zorch6:2345/_layouts/FirstPointUserDrivenRoutes/Default.aspx
x-requested-with: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2; MS-RTC LM 8; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: zorch6:2345
Content-Length: 16
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: MSOWebPartPage_AnonymousAccessCookie=2345; WSS_KeepSessionAuthenticated=2345; previousLoggedInAs=; loginAsDifferentAttemptCount=


Prototype has the correct ordering of calls to XHR to initiate the request, so I’m baffled by what could be causing this issue.

Any thoughts would be appreciated.

- Chuck

The reason might that you try to run files iles locally, which won’t work in Internet Explorer. Makes sure they’re on a server and things should work fine for you (I hope).

I’m glad it helped!

I had the same problem, IE7 allowed only one request and then XHR “died”. Solution really was to set XHR.onreadystatechange after calling XHR.open();

Cheers!

At the end, it was the order of the code that was the culprit.

I just set the “ID” of may AJAX request (I’m using conio which still uses the initial JSON-RPC spec) to a random number (could append to ID if you’re actually using it for something)

getTheContent()
{
createXMLHttpRequest();
blah..
blah..
blah..
}

I’m glad it helped!

Hmm, interesting. When it comes to Firefox and the abort method (a problem I’ve been facing as today, actually), the approach and description by Peter-Paul Koch described in XMLHTTP notes: abort() and Mozilla bug solves it.

Invoking this method must initialize the object by remembering the method, URL, async (defaulting to true if omitted), user (defaulting to null if omitted), and password (defaulting to null if omitted) arguments, setting the state to open, resetting the responseText, responseXML, status, and statusText attributes to their initial values, and resetting the list of request headers.

In addition, when the state is not uninitialized, all members of the object with the exception of onreadystate must be set to their initial values and user agents must behave as if abort() was invoked.

My rough and ready tests indicate that this isn’t necessarily how things work in the wild though… Firefox in particular seems to get a little upset if abort() isn’t invoked, but gets upset a different way if it is

Thanks for the info! However, the abort method should still be important for other web browsers, right? To stop the current connection and start a new one.

Xmlhttp.open has a “reset” semantic so the second open() call on the same object will abort the previous connection, disconnect previous event handler, and reset the object.

(This means that you don’t need to invoke the abort method, either.)

Very good points! Thank you for contributing!

Interesting approach. If the problem persists, it’s definitely something to try.

I changed the URL and appended Math.random() and it fixed the problem outright.

Ha ha!
Actually, it’s quite interesting. The pre-formatted source code is indeed indented with tabs, but when saving/publishing a post with WordPress, it replaces the tabs with spaces.

Man, that is a hawk eye thing to notice something like that!