Skip to main content
W
wnix
Inspiring
October 11, 2022
Answered

400 bad request yet the request got processed

  • October 11, 2022
  • 1 reply
  • 1108 views

We have an ajax request that got a "400 bad request" response from our server. The weird thing is, the request got fully processed by CF. How is that possible?

Is it possible for the server to see the request as "bad", yet it still allows it to be processed?

    This topic has been closed for replies.
    Correct answer wnix

    CF definitely did manage to receive and processe the request, because there are a bunch of cfhttp requests that would only be run if the CF code in question are executed, and we know the cfhttp requests definitely did run because our custom logging routine logged all the relevant details.

     

    Yes it's a weird one, and I've found the culprit - I forgot to encode the xml string before sending it with the ajax request. And for some reason, if you do that, the server would still process the request (albeit with the form being completely blank), but respond with a 400 error at the end of it.

     

    Here's a simple test to replicate this behavior:

    var url = "http://localhost/test.cfm";
var xhr = new XMLHttpRequest();
xhr.open("POST", url, true);

xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");

xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
console.log(xhr.status);
console.log(xhr.responseText);
}};

var data = "blah=1&xml=<company><![CDATA[blah & blah]]></company>";

xhr.send(data);

     

    1 reply

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    October 11, 2022

    A 400 status indicates that the server (your web server, more likely than cf) had some problem with the client request. As such, no, that should not have somehow been passed to cf.

     

    But there are at least a couple possible explanations:

    • your web server was configured to process error codes by passing them to cf. But what's your proof that it did work? Some db update or cfmail or log line that was written? Could that have come from some cf "error" page processing such a 400 "error"? 
    • The request that "worked" might have got through after (or before) the failing one. You could watch with your browser dev tools, and its network tab, with its feature enabled to not clear its log on each request

     

    Or maybe others will have better ideas. 

    /Charlie (troubleshooter, carehart. org)
    W
    wnixAuthorCorrect answer
    Inspiring
    October 11, 2022

    CF definitely did manage to receive and processe the request, because there are a bunch of cfhttp requests that would only be run if the CF code in question are executed, and we know the cfhttp requests definitely did run because our custom logging routine logged all the relevant details.

     

    Yes it's a weird one, and I've found the culprit - I forgot to encode the xml string before sending it with the ajax request. And for some reason, if you do that, the server would still process the request (albeit with the form being completely blank), but respond with a 400 error at the end of it.

     

    Here's a simple test to replicate this behavior:

    var url = "http://localhost/test.cfm";
var xhr = new XMLHttpRequest();
xhr.open("POST", url, true);

xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");

xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
console.log(xhr.status);
console.log(xhr.responseText);
}};

var data = "blah=1&xml=<company><![CDATA[blah & blah]]></company>";

xhr.send(data);

     

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    October 11, 2022

    Interesting, indeed. Thanks for the update. 

    /Charlie (troubleshooter, carehart. org)
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices