Missing POST data in IE6/7
- We have a fairly large app running on top of the basic Y!UI utils and
have noticed something quite strange.
Once in a blue moon, an XHR POST is made to the server with no
content. This happens on both a programmatically built POST as well as
a parsed form POST. In one instance, both a form POST and a
programmatically built POST were made one second apart with both
requests missing their POST data. The Content-length also comes
through as 0.
We searched the forums here and found the user that was not getting
POST data due to the header type including "utf-8". We double-checked
the headers that are getting sent and they indeed
"application/x-www-form-urlencoded" as stated in their fix.
We have users using IE6 - 7 and Firefox 1.5 - 2.0 and have only
noticed the problem with IE users (with various different user
agent's.) Whatever the problem is, it always seems to rectify itself
on subsequent requests.
We have added some logging into the Connection library to try and
trace it to a JS error, but I am starting to think that IE's XHR
Object is munging the data.
Has anyone else had this problem?
>I have noticed one or two reports where an initial request in IE
> We have a fairly large app running on top of the basic Y!UI utils and
> have noticed something quite strange.
> Once in a blue moon, an XHR POST is made to the server with no
> content. This happens on both a programmatically built POST as well as
> a parsed form POST. In one instance, both a form POST and a
> programmatically built POST were made one second apart with both
> requests missing their POST data. The Content-length also comes
> through as 0.
> We searched the forums here and found the user that was not getting
> POST data due to the header type including "utf-8". We double-checked
> the headers that are getting sent and they indeed
> "application/x-www-form-urlencoded" as stated in their fix.
> We have users using IE6 - 7 and Firefox 1.5 - 2.0 and have only
> noticed the problem with IE users (with various different user
> agent's.) Whatever the problem is, it always seems to rectify itself
> on subsequent requests.
reports a communication failure, but a retry or subsequent requests
succeed. Unfortunately, the reports did not include functional
examples or code posts that would allow further debugging.
Can you tell me anything about your application/environment that would
help me trace the cause of this condition?
- I would love to provide more details... but there just don't seem to
Here is an overview of what we have discovered so far. We have an
XHR-heavy web application built with ExtJS on top of Y!UI with Ruby on
Rails on an Apache web server. We only see the problem with IE6/7
users and it happens very infrequently. And when it does occur, the
very next request with the same parameters works just fine.
We have sprinkled some GET XHRs into the connection util which log the
current state of the POST request back to the server so that we can
check that the client-side code is indeed parsing and building the
request as it should. We also log any server errors (500s, etc) back
to the server as well.
We are also unable to reproduce the problem at all.
Here is a run down of what happens.
The user accesses the site and a session ID is set.
The user uses the site to build their order.
Once the order is set, they request a price quote by filling out a
form that is sent via a POST XHR to the server.
The mongrel logs show that a POST request of 0 length is received.
Seeing no session ID, the server re-assigns that user a new session ID
and then proceeds with the quote request. The Ruby on Rails code
expects a certain parameter to be present. Since the request is empty,
the code returns a 500 error, logs it locally, and sends an email to
A few seconds later, the client makes another request with the exact
same parameters and everything proceeds as normally.
As far as we can tell, the client does not encounter any JS errors
during this process (because a request IS made). We also do not get
any indication that the client received the 500 error since we log
those back to the server (using a XHR GET)
Our current theory is that IE is generating a mangled header or the
XHR ActiveX object is just flat-out broken. Our client-side debugging
logs show that the request is being built correctly. But for some
reason, IE never sends any data with the request. The server responds
to this empty request with the 500, but the broken XHR ActiveX object
never gets the response and/or never updates its readyState (or
perhaps the readyState is set to something not expected?). Seeing no
response from the server, the request times out and the user makes a
second request. At this point, everything works just fine and a quote
is returned to the user.
Does that help any? We have been scratching our heads for over a week
on this one!
Has anyone else heard of any problems with POST XHRs in IE?
- Another update. We have finally been able to reproduce the problem,
but can't get enough information around what exactly is going on. It
appears as if the problem occurs only in unpatched versions of IE6
(and we assume unpatched IE7 as well.)
We have tried to install Fiddler to check out what the connection
status is, but it requires .NET and we are scared that installing that
may patch up IE6 and solve the issue.
Our current theory is this... When the client-side determines that a
connection is taking too long, it calls Y!UI's abort method. Since
these requests are POSTs, they can't actually be aborted. In our
particular scneario, two POSTs are performed with one click, so we
already have 2 POSTs getting processed at one time. Seeing the timed
out request, the user hits the button again, creating a third and
fourth request (automatically aborting the 2nd request if it hasnt
At this point, since IE only supports 2 connections per domain, we now
have 2 aborted POST requests that are still open, and two new pending
POSTs. We think the problems occurs when one of the queued POST
requests times out before it is ever given a chance to connect to the
server. But again, since the POSTs can't really be aborted, when the
server finally gets a chance to respond and ask the client for the
POST data, the client has already moved on and done something else. As
with. This is why the server gets the request and the headers, but no
POST data. It would also explain why we never see any errors reported
by the client. Y!UI has already removed all of the callbacks from the
Is that a possible scenario?