Originally Posted by SquidScareMe
Thanks Alien51. You just saved me.
I stumbled on this thread because I'm encountering the same issue.
The symptoms are exactly the same:
1) Works fine every time in FF3,
2) Works fine every time in IE if Fiddler is running (very odd)
3) Works fine every time in IE if I use CTRL+F5
4) Works only
the first time in IE if I just hit refresh or use F5
5) Works fine in IE and I can make the same call over and over again as long as I don't refresh the page (then it breaks to scenario 4)
So the twist here is that I'm using prototype 184.108.40.206 (the latest release). To ensure that this isn't isolated to prototype, I also tried with the latest release of jQuery. Same deal.
I didn't check jQuery source, but at least with prototype, the order of operations seems to be correct. Here is the relevant section of code (lines 1214-1223 of prototype.js):
if (this.options.asynchronous) this.respondToReadyState.bind(this).defer(1);
this.transport.onreadystatechange = this.onStateChange.bind(this);
this.body = this.method == 'post' ? (this.options.postBody || params) : null;
As I mentioned, since Fiddler interferes with the manifestation of this error, I used WireShark to trace the messages on the server. It seems that on the unsuccessful calls, the HTTP message has a content length header set to 0 (and thus, I'm assuming, the POST body content is not being supplied, even though I haven't changed the request). Of course the mystery is why this is the case considering that I'm able to use the ASP.NET AJAX libraries all day long without drama on IE.
I've added trace messages after the call to this.transport.send(this.body) just to ensure that the body content is indeed included and the result is positive (the intended content is there), however, the content length on the request (and possibly the content itself is not being sent) is 0.
So any help would be much appreciated.
To add a twist, it all works fine with the YUI connection manager...
I take it back...it doesn't work with YUI either...