Question

I’m receiving an error sometimes for what should be a valid request as “400 OK” when I PUT some arguments to a URL.

The same URL and arguments will work 99% of the time, but I’m seeing errors crop up in our logs.

Is that an obscure thing that can happen due to some factors or is something specific to my app causing the mish-mash of strange headers? I’m guessing it’s the latter if there’s no answers to the former 🙂

UPDATE

For the comments, “it” is a relatively simple RESTful API that was written. Now it’s almost always giving back the right headers like 400 and body of error or 200 with body of ok. When a bad header makes it to the web client, the web client is pinging a reporting URL with the message it got so we can differentiate API errors between our web app and mobile apps. As far as we know there is no combintation of code that would make this “400 OK” hell. But seeing as it seems impossible for that to happen outside of our code messing up, I’m going to take a deeper look.

UPDATE 2

Okay I’ve delved deeper into our framework than I have in a long time and spoke with some devs.

It returns the information via the AJAX call to the API to the browser.

The browser detects a “400 OK” and sends it back to our server, where we are getting this strange report. No one has seen this happen with their eyes, but the logs say it’s happening.

There is literally zero code in our codebase that would return 400 OK since the only 400 in our HTTP header handlers are “400 bad request”

I’m wondering now if there’s some browser/jquery/ajax bug I’ve stumbled into.

UPDATE 3 (because you can’t have too much information)

I checked how the browser sees what’s wrong. A callback is fired on failure as reported by jQuery $.ajax. We then have code like this:

xhr.always(function() {
  var request = [ this.type, this.url, this.data ].join(' '),
      response = [ xhr.status, xhr.statusText, xhr.responseText ].join(' ');

  $.ajax({ 
    url   : REPORTING_URL,
    type  : 'POST', 
    data : { request : request, response : response }
  });
});

And we know this works “most” of the time because we also received “400 error” responses from these ajax calls

UPDATE 4

I just noticed that literally all the errors came from user agent:

Mozilla webkit etc...... AdobeAIR/1.5.3 which is a very old version

Our AIR app just has an iframe of our web app. I can only imagine what’s happening there.

Answer 1

After @pst’s great answer which I marked as the official answer, I found a more depressing answer that was 100% true for my case.

This header was coming via using a website in an iframe for users of Adobe AIR 1.5.3.

After force-upgrading all of our AIR users it went away so it’s safe to assume this was a bug of their header reporting.