Loading ...
Sorry, an error occurred while loading the content.

Missing POST data in IE6/7

Expand Messages
  • Derek
    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
    Message 1 of 4 , Jul 13 1:33 PM
    • 0 Attachment
      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?
    • tssha
      ... I have noticed one or two reports where an initial request in IE reports a communication failure, but a retry or subsequent requests succeed.
      Message 2 of 4 , Jul 13 2:57 PM
      • 0 Attachment
        --- In ydn-javascript@yahoogroups.com, "Derek" <tkvgzcf02@...> wrote:
        >
        > 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.

        I have noticed one or two reports where an initial request in IE
        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?

        Regards,
        Thomas
      • Derek
        I would love to provide more details... but there just don t seem to be any! Here is an overview of what we have discovered so far. We have an XHR-heavy web
        Message 3 of 4 , Jul 25 6:48 AM
        • 0 Attachment
          I would love to provide more details... but there just don't seem to
          be any!

          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
          our admins.
          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?
        • Derek
          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
          Message 4 of 4 , Aug 1, 2007
          • 0 Attachment
            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
            finished.)

            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
            far as the JavaScript is concerned, the connection is over and done
            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
            connection.

            Is that a possible scenario?
          Your message has been successfully submitted and would be delivered to recipients shortly.