Home/ Questions/Q 1006739
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:30:31+00:00

I’ve got a jQuery function that’s posting to the server using $.ajax and it

  • 0

I’ve got a jQuery function that’s posting to the server using $.ajax and it works fine in IE, Chrome and Safari, but in Firefox, no POST values are being received by the server. When i query the form collection (using classic ASP), i get undefined for all the values

 $.ajax({
    type: 'POST',
    url: url,
    dataType: "text",
    data: { value1: true, value2: false },
    success: function(html) {
       // removed for clarity
    },
    error: function(xhr, ajaxOptions, thrownError) {
       // removed for clarity
    }

It’s definitely hitting the server, and when i look at the values in FireBug, it shows exactly what i would expect for the POST, but somewhere, the data is going missing

To make matters more confusing, which i run it on IIS locally, it works fine in all browsers.

It’s not doing a cross domain post as the url is generated depending on which domain it’s running on, so i’ve not left any hard coded values in that could be causing the problem

I guess it’s somthing simple i’ve missed, but for the life of me, i can’t see what

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The short answer:

    When submitting an HTTP POST, most browsers (all except Firefox, as far as I can tell) will send the HTTP request headers in one TCP/IP frame, and then begin a fresh second frame for the actual POST data, even if it could (theoretically) all fit in a single frame. Firefox doesn’t do this – it’ll send the POST data in the same frame as the request headers, spilling over into multiple frames only if the total request (headers + POST data) won’t fit in a single frame. There appears to be a bug in IIS 7.0 such that when an HTTP POST is handled by a custom 404 error handler page, any POST data contained in the same TCP frame as the initial request is discarded.

    The filthy dirty workaround is to ensure the first thing in your form is 1460 bytes’ worth of padding – <input type="hidden" name="padding" value="xxxxxxx...." /> should do it – and the second thing is a dummy name/value pair to work around parsing errors caused by the padding – <input type="hidden" name="splitter" value="1" />. Subsequent form values should then show up as normal in the Request.Form collection.

    For the long answer and explanation of how we worked all this out, see this post on my blog.

    • 0