AJaX submit giving 404 after working for years [was: It worked.. until it didn't.]

[WolfShade]

Hello, all,

I've got a CFC that accepts an AJaX submitted form that has been converted to JSON, converts it back into a form, does form validation, and then puts everything into an Excel spreadsheet.  Been working flawlessly for years.

I'm in the middle of changing the CAPTCHA, and suddenly I'm getting a 404 error in response.

Diagnostics: Failed to add HTML header. ColdFusion was unable to add the header you specified to the output stream. 
This is probably because you have already used a cfflush tag in your template or buffered output is turned off. 
The error occurred on line 352.

Line 352 of the CFC is:

returnSOrigin &= "<p style='margin:0 20px; text-indent:-20px;'>POE for Shipment Origin for Cargo #val(sdLoop)# does not exist in form.</p>" & application.crlf;

There is no CFFLUSH being used _anywhere_ in this process.  It was working on Friday, now this.  Any thoughts?

V/r,

^ _ ^

[James Moberg]

Are you generating any white space that may be in the output buffer that is forcing ColdFusion to start flushing?  Which version (& patch level) of ColdFusion are you using?  What is the size of your "Maximum Output Buffer size" ? Which web server are you using?

[WolfShade]

Hi, Jamo,

No change has been made to what is returned after the form submit, so no whitespace has been added.  Matter of fact, nothing has been changed in the CFC that the AJaX submits to, other than checking the session scope for the value inserted into the image to make sure that they match what the user entered.  It's still using the same response (either it doesn't match, or nothing at all if it does match.)

As far as CF version, we are on CF11 update 19.  Maximum output buffer size I can find out after our SA gets in, probably about an hour from now.  We are using Apache 2.2x.

V/r,

^ _ ^

[Charlie Arehart]

I doubt the problem has anything to do with the line indicated. That's simply "the straw that broke the camel's back". (Are we allowed to use that phrase anymore? Or do I need to fear triggering someone about the poor camel?)

Instead, and assuming that the output buffer size has not been decreased (see James' comment), I'd question what has changed about the nature and VOLUME of the generated output on the page. You say you were only changing the captcha. If you revert to the original, does the problem go away? What is different about the new captcha?

Have you compared the page source (in your browser) between the old and new code versions, to see what differs? Note there are underlying Java objects in CF (and Tomcat) that can track the actual output buffer, while it's being built in CFML. Finally, if you have FusionReactor, note that it has a nifty "Request content capture" feature, that can be turned on to track all the request and/or response content of every request. it can be dangerous if left on but for a quick need like this, it can be gold.

[Charlie Arehart]

And one more thing: make sure it's not perhaps caused by some change in the application.cfc or cfm under whose control your page runs.

[WolfShade]

https://forums.adobe.com/people/Charlie+Arehart  wrote

(Are we allowed to use that phrase anymore? Or do I need to fear triggering someone about the poor camel?)

I try to err on the safe side.  But, who knows what will trigger whom, these days?  I've given up trying to keep up.

https://forums.adobe.com/people/Charlie+Arehart  wrote

You say you were only changing the captcha. If you revert to the original, does the problem go away? What is different about the new captcha?

Not sure I want to go through and revert the code to the original.  The original was poorly designed and easily bypassed.

The new CAPTCHA has had issues from the start, mostly because we can't use CFIMAGE writetobrowser.  Still haven't figured out why, but it's either a permissions issue to the /CFFileServlet folder, or something related to the STIG that we have to live with.  So, I'm using CF to randomly pick six alpha/numeric/character, save that to a session variable, place it in a CAPTCHA image object, converting to Base64, and inserting it into the src attribute of an image tag.  Something like:

src="data:image/*;base64,#toBase64({blob})#"

And, to be honest, I'm not sure this will work.  We've had issues in the past where session variables work in staging and development, but fail in production because every click generates a new JSESSIONID.  So, this may all be in vain.

V/r,

^ _ ^

[WolfShade · Accepted solution]

Nevermind.  It's apparently fixed itself.  And nothing was changed.  No config/settings.  No code.  No reboots of servers (workstations are rebooted automatically every night.)  It just.. started working, again.

This is not an isolated case.  This has been happening for at least the 7+ years that I've been here.  Something works flawlessly; then it stops working for a day or two; then it miraculously is fixed.

I've given up trying to understand it.  I just accept it as a part of working, here.

V/r,

^ _ ^