While trying to update the WP LinkedIn widget on a WordPress blog, I ran into an HTTP error I had never seen before: 414.
HTTP error 414 indicates that the URI is too long for the web server to interpret it.
In the case of a WordPress blog, this is likely caused by a security feature of the iThemes security plugin. If iThemes is being used, the first step would be to turn off the “Filter Long URL Strings” checkbox. This can be accessed through the WordPress admin console: Security –> Settings –> System Tweaks.
The checkbox is about halfway down the page.
I would suggest turning this off only long enough to complete whatever administrative action you are doing, and then turning it back on, so as not to create an unnecessary vulnerability.
Transferring files from a UNIX or Linux server when FTP is not installed can be tricky. In my case, there was a set of log files that I needed to send to someone for analysis. After discovering that FTP was not set up on the server, I decided to try another route: zipping the logs into a single file and emailing the file to me.
First, I had to zip the files. The zip command was easy enough:
zip <zipped filename> <files to be zipped>
Next, I had to mail the zipped file. Fortunately, mailx was installed! Using this in conjunction with uuencode, and the file would be on its way.
uuencode <original filename> <final filename> | mailx -s <subject of email – put in quotes> <email address>
Be sure to check your junk or spam folder, as email from the server could end up there.
In case you decide not to enter a license key upon installing CF 2018, or if you entered one at installation, but want to enter a different one to upgrade between versions, there doesn’t seem to be any documentation on where to do that.
The System Information screen can be accessed by clicking the “i” in a circle in the upper right-hand corner of the admin screen.
In the System Information screen, enter your license key into the New License box and click Submit Changes.
In the process of finally banishing Adobe ColdFusion 8 from my application servers and completing the transition to CF 11, I came across what is apparently a little-known change in the operation of the CFPROCPARAM tag inside a CFSTOREDPROC tag.
After moving the website from CF 8 to CF 11, there were no major changes that had to be made. However, one particular action kept causing a dialog box to pop up:
I was able to trace the source of the dialog box to an error handler of sorts, but in this case, the error was quite nebulous. The error code “HANDLEDATABASEERROR” didn’t really tell me much. It appears that it may have come from Java itself.
After tracing back which function call seemed to be causing the problem, I discovered that the call to the SQL stored procedure was not using the correct parameter names – that is, names that matched the ones in the stored proc itself.
To determine if the database activity was actually the source of the error, I turned on Log Activity in the Data Source in the ColdFusion Administrator: Data Sources –> (specific Data Source Name) –> Show Advanced Settings –> Log Activity checkbox and text box showing where the log file will go. Example:
After reloading the web page and doing the same action, the an error like the one below showed up in the dblogs.txt file:
spy(ajp-bio-8014-exec-6)(2018/09/26 12:42:30.326)>> java.sql.SQLException: [Macromedia][SQLServer JDBC Driver][SQLServer]Procedure or function 'sp_getNameSuggestion' expects parameter '@GoodParamName', which was not supplied. ErrorCode=201 SQLState=HY000
java.sql.SQLException: [Macromedia][SQLServer JDBC Driver][SQLServer]Procedure or function 'sp_storedProcName' expects parameter '@GoodParamName', which was not supplied.
at macromedia.jdbc.sqlserverbase.ddcw.b(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddcw.a(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddcv.b(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddcv.a(Unknown Source)
at macromedia.jdbc.sqlserver.tds.ddr.v(Unknown Source)
at macromedia.jdbc.sqlserver.tds.ddr.a(Unknown Source)
at macromedia.jdbc.sqlserver.tds.ddq.a(Unknown Source)
at macromedia.jdbc.sqlserver.tds.ddr.c(Unknown Source)
at macromedia.jdbc.sqlserver.dda3.m(Unknown Source)
at macromedia.jdbc.sqlserverbase.dde7.e(Unknown Source)
at macromedia.jdbc.sqlserverbase.dde7.a(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddd2.a(Unknown Source)
at macromedia.jdbc.sqlserverbase.dde7.x(Unknown Source)
at macromedia.jdbc.sqlserverbase.dde7.t(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddd2.execute(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddd6.execute(Unknown Source)
at macromedia.jdbcspysqlserver.SpyPreparedStatement.execute(Unknown Source)
The CFML source code calling this stored procedure was revealing:
In some older versions of ColdFusion (at least as recently as version 8, perhaps all the way through 10), if the name of the parameter stored in the dbvarname attribute of the cfprocparam tag wasn’t correct, no error was thrown as long as the data types of the parameters matched in the correct order for both the cfstoredproc tag and the database stored procedure. This dbvarname attribute was essentially ignored in those versions. Version 11 changed all that.
By changing the source code to reflect the correct name, the bug was fixed.