Highlighted

Coldfusion 2016 Issue with .htaccess after upgrade to level 14

New Here ,
Mar 20, 2020

Copy link to clipboard

Copied

I am running on linux using Apache httpd-2.4.41, with the latest JDK and Coldfusion 2016.  Everything worked great through update 13.  However, after applying update 14 and after doing the wsconfig -upgrade, I now have an issue where when a user attempts to connect to a page or directory that does not exist, it displays a 403 error.  In addition, I noticed that my .htaccess rules seem to now be completely ignored.

When I roll back to version 13, everything works normal again.

 

Has anyone else experienced or am I the only lucky one that is dealing with this.  

Adobe Community Professional
Correct answer by Charlie Arehart | Adobe Community Professional

I can share an update on this: the problem Jim was experienging (as are others) is indeed down to the use of htaccess (and maybe also true for rewrites via mod_rewrite). The rewrite is adding a new header, in the request sent from Apache to CF--and thus the updated connector (in CF) fails the request for it not having one of the allowed (dozen) headers that are listed in the Tomcat docs (http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html).

 

And THAT is why Jim (and others) would conclude they have to use that regex value of ".*"  (for "anything"). I am working on determining if there's a way to add ONLY the extra header that is needed, rather than allowing "any" (which was indeed what the Tomcat fix was trying to prevent).

 

BTW, for anyone who wants to see WHAT header IS being sent in on requests that ARE sent to CF via a rewrite, you can see it, either of two ways. (Let me note that you can of course only see it when the request IS working, such as when you use that .* pattern, or if you roll back the update.)

 

One way is with the CFML function gethttprequestdata (or more specifically, coldfusion gethttprequestdata().headers). Another way is with FusionReactor, and its ability to see the "details" of a request, one of which is a "headers" tab. As I was working with one client, we found the header to be XSite-name.

 

And yes, we tried adding that as THE pattern. We did have to escape the "-" within the name, so "Xsite\-name". And that "worked" (in that now the "rewritten" site would run). And BTW, sites that were NOT being "rewritten" were working regardless. 

 

What's not clear from the Tomcat docs is whether in doing that, we are ADDING to or OVER-RIDING/overwriting the default values listed on the Tomcat doc page. Again, I plan to do some more research and testing on things. (I find virtually none by anyone else on the web.)

Views

835

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Coldfusion 2016 Issue with .htaccess after upgrade to level 14

New Here ,
Mar 20, 2020

Copy link to clipboard

Copied

I am running on linux using Apache httpd-2.4.41, with the latest JDK and Coldfusion 2016.  Everything worked great through update 13.  However, after applying update 14 and after doing the wsconfig -upgrade, I now have an issue where when a user attempts to connect to a page or directory that does not exist, it displays a 403 error.  In addition, I noticed that my .htaccess rules seem to now be completely ignored.

When I roll back to version 13, everything works normal again.

 

Has anyone else experienced or am I the only lucky one that is dealing with this.  

Adobe Community Professional
Correct answer by Charlie Arehart | Adobe Community Professional

I can share an update on this: the problem Jim was experienging (as are others) is indeed down to the use of htaccess (and maybe also true for rewrites via mod_rewrite). The rewrite is adding a new header, in the request sent from Apache to CF--and thus the updated connector (in CF) fails the request for it not having one of the allowed (dozen) headers that are listed in the Tomcat docs (http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html).

 

And THAT is why Jim (and others) would conclude they have to use that regex value of ".*"  (for "anything"). I am working on determining if there's a way to add ONLY the extra header that is needed, rather than allowing "any" (which was indeed what the Tomcat fix was trying to prevent).

 

BTW, for anyone who wants to see WHAT header IS being sent in on requests that ARE sent to CF via a rewrite, you can see it, either of two ways. (Let me note that you can of course only see it when the request IS working, such as when you use that .* pattern, or if you roll back the update.)

 

One way is with the CFML function gethttprequestdata (or more specifically, coldfusion gethttprequestdata().headers). Another way is with FusionReactor, and its ability to see the "details" of a request, one of which is a "headers" tab. As I was working with one client, we found the header to be XSite-name.

 

And yes, we tried adding that as THE pattern. We did have to escape the "-" within the name, so "Xsite\-name". And that "worked" (in that now the "rewritten" site would run). And BTW, sites that were NOT being "rewritten" were working regardless. 

 

What's not clear from the Tomcat docs is whether in doing that, we are ADDING to or OVER-RIDING/overwriting the default values listed on the Tomcat doc page. Again, I plan to do some more research and testing on things. (I find virtually none by anyone else on the web.)

Views

836

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Mar 20, 2020 0
Adobe Community Professional ,
Mar 21, 2020

Copy link to clipboard

Copied

Jim, you say that this only about requests for page that DON'T exist? And directories that don't?

 

So requests to pages or folders that DO exist work fine? That seems odd, but would suggest something happening with any 404 handler, set in either your web server or cf (in the admin or your code).

 

If this was about ANY requests to the site, I'd have suspected the need to update the connector. And there may still be an issue.

 

I know you said you did that, but perhaps it's that the wsconfig upgrade did not update the actual files that apache is using. Follow the config from httpd.conf, to any included conf that references cf config, and then ultimately its pointer to the workers.properties file. Make sure THAT file has a line (like the several others there) that now names a secret. That's what the new update implements.

 

More in a post I did here:

 

https://www.carehart.org/blog/client/index.cfm/2020/3/20/how_and_why_sites_may_break_after_Mar_2020_...

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

Thanks for the reply.

So, this one really has got me stumped.  I have confirmed that the connector was rebuilt.  Here is the log:

 

03/20 15:30:57 debug Using Apache binary /usr/local/apache2/bin/httpd
03/20 15:30:57 info Server version: Apache/2.4.41 (Unix)
03/20 15:30:57 debug Exec'ing chmod +x /opt/coldfusion2016/config/wsconfig/1/mod_jk.so
03/20 15:30:57 debug Set permission to execute on /opt/coldfusion2016/config/wsconfig/1/mod_jk.so
03/20 15:30:57 debug Created file /opt/coldfusion2016/config/wsconfig/1/mod_jk.so

 

I have checked the workers.properties and worker.cfusion.secret has been set.

My config file does show that it is pointing at the correct locations for the connector.

To give more information, here is what I have:

 

When I connect to the website and land on a page that exists, everything works like it should.  (Originally, when I first upgraded to 14, I got the 403 error for everything and that is when I first upgraded the connector)

 

If I attempt to go to a webpage that does not exist BUT I have the extension .cfm, then I get the coldfusion error page with the File Not Found Message and the stack trace.  (If I enable the coldfusion configuration to redirect missing pages, then this will redirect to the redirect page) 

 

However, if I attempt to connect to a webpage that does not exist and does not have the .cfm extension then I get this:

HTTP Status 403 – Forbidden


Type Status Report

Description The server understood the request but refuses to authorize it.


Apache Tomcat/8.5.42

 

I also get that same message if I attemp to go to a directory that does not exist.

What is strange is that if I put in a .htaccess file and attempt to put rules to redicrect for missing pages, it is as though the .htaccess file does not even exist and is completely ignored.  (We had been using .htaccess before the latest update without issue)

 

From what I can surmise from all of this, it appears that when a user connects to the website, no matter what page is called for, everything seems to be passed to the connector and is either processed by coldfusion.  If the page is there, all is good.  If not, tomcat and not apache, seems to take the lead and just puke.

 

One other thing that I noticed in the /opt/coldfusion2016/config/wsconfig/1/mod_jk.log log file is that when I attempt to connect to a webpage that does not exists, I get this in the log:

[Sat Mar 21 08:04:03 2020] [30757:2942241648] [warn] ajp_process_callback::jk_ajp_common.c (2218): (cfusion) AJP13 protocol: Reuse is set to false

 

I have no clue what that means or if it is relavant.  

 

Any additional ideas that you might have would be greatly appreciated.

 

Thanks!

 

 

 

 

 

 

 

 

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

One additional note.  In my last response I mentioned that when I watched the log file /opt/coldfusion2016/config/wsconfig/1/mod_jk.log if I went to a page that did not exist I would see this message:

[Sat Mar 21 08:04:03 2020] [30757:2942241648] [warn] ajp_process_callback::jk_ajp_common.c (2218): (cfusion) AJP13 protocol: Reuse is set to false

 

However, when the update is not applied and I roll back to version 13, then when I go to a page that does not exist, there is no log message at all.   I still don't know exactly what this means but it seems like there is something relevant happening here.  I feel like the connector is somehow gettng involved when it shouldnt.  But again, this is not my area of expertise at all. 🙂

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
Adobe Community Professional ,
Mar 21, 2020

Copy link to clipboard

Copied

That error line says you are running tomcat/8.5.42. But you said you applied CF2016 update 14, which (along with CF2018 update) should be instead reporting tomcat/9.0.21 in any such error message. [UPDATE: I was mistaken here. It's 8.5.42 for CF2016 with update 14. See a new, later comment from me for clarification.]

 

So first, you should make sure that the CF update really worked, without error. I have a blog post that shows what to check (there's an update log, and you want to make sure it shows a count of 0 fatalerrors). See the post with more, here:

https://coldfusion.adobe.com/2019/03/problems-applying-cf-update-check-first/

 

Second, even if that proves to show 0 errors (and please, do check), then the problem may be that your running of the wsconfig tool may have "worked", but it may have put the mod_jk.so file into a folder that is NOT the one that your apache conf files are looking at.

 

Or if that seems correct, then check to make sure that that mod_jk.so (that Apache does point to) is dated Mar 2020 (and not Dec 2019 or earlier, which would be OLD connector files).

 

Let us know what you find.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

I really apprecaite your time on this. I am truly pulling my hair out.

 

I have also confirmed the date on mod_jk.so

-rwxr-xr-x. 1 root root 958177 Mar 13 10:34 /opt/coldfusion2016/config/wsconfig/1/mod_jk.so

 

I also checked one more time on the path in httpd.conf file:

Include "/usr/local/apache2/conf/mod_jk.conf"

 

And the paths in /usr/local/apache2/conf/mod_jk.conf:

LoadModule jk_module "/opt/coldfusion2016/config/wsconfig/1/mod_jk.so"
# Where to find workers.properties
JkWorkersFile "/opt/coldfusion2016/config/wsconfig/1/workers.properties"
JkMountFile "/opt/coldfusion2016/config/wsconfig/1/uriworkermap.properties"

 

I have also checked in the install log which I will include below and it shows no issues.

You mentioned that I should be on a totally different version of Tomcat after the upgrade.  Obviously that is very concerning since now I am trying to figure out how the upgrade appears to have worked without issue and yet I am on an incorrect version of tomcat.  Any ideas as to what I can look at to see why Tomcat did not upgrade or a way that I can manually upgrade Tomcat?  Again, thanks for your time with this! 

 

Below is the log from the install:  (I only included the log up to where it reports the success count)


Fri Mar 20 03:07:52 PDT 2020

Free Memory: 21592 kB
Total Memory: 53012 kB

4 Command Line Args:
0: -i
1: silent
2: -f
3: /opt/coldfusion2016/cfusion/hf-updates/hf-2016-0014-318307.properties

java.class.path:
/opt/coldfusion2016/cfusion/hf-updates/hotfix-014-318307.jar

ZGUtil.CLASS_PATH:
/opt/coldfusion2016/cfusion/hf-updates/hotfix-014-318307.jar

sun.boot.class.path:
/usr/jdk1.8.0_202/jre/lib/resources.jar
/usr/jdk1.8.0_202/jre/lib/rt.jar
/usr/jdk1.8.0_202/jre/lib/sunrsasign.jar
/usr/jdk1.8.0_202/jre/lib/jsse.jar
/usr/jdk1.8.0_202/jre/lib/jce.jar
/usr/jdk1.8.0_202/jre/lib/charsets.jar
/usr/jdk1.8.0_202/jre/lib/jfr.jar
/usr/jdk1.8.0_202/jre/classes

java.ext.dirs:
/usr/jdk1.8.0_202/jre/lib/ext
/usr/java/packages/lib/ext

java.version == 1.8.0_202 (Java 1)
java.vm.name == Java HotSpot(TM) Client VM
java.vm.vendor == Oracle Corporation
java.vm.version == 25.202-b08
java.vm.specification.name == Java Virtual Machine Specification
java.vm.specification.vendor == Oracle Corporation
java.vm.specification.version == 1.8
java.specification.name == Java Platform API Specification
java.specification.vendor == Oracle Corporation
java.specification.version == 1.8
java.vendor == Oracle Corporation
java.vendor.url == http://java.oracle.com/
java.class.version == 52.0
java.library.path == /opt/coldfusion2016/cfusion/bin/../lib:/opt/coldfusion2016/cfusion/bin/../lib::/usr/java/packages/lib/i386:/lib:/usr/lib
java.compiler == null
java.home == /usr/jdk1.8.0_202/jre
java.io.tmpdir == /tmp
os.name == Linux
os.arch == i386
os.version == 2.6.35.14-106.fc14.i686
path.separator == :
file.separator == /
file.encoding == UTF-8
user.name == nobody
user.home == /
user.dir == /opt/coldfusion2016/cfusion/bin
user.language == en
user.region == null
__________________________________________________________________________

Installed Feature(s) Standard, J2EE of Adobe ColdFusion 2016 Update 14

Install Begin: MARCH 20, 2020 3:06:45 PM PDT
Install End: MARCH 20, 2020 3:07:51 PM PDT

Installed by InstallAnywhere 19.0 Premier Build 6112


User Interactions
-----------------


#Install
#-------
-fileOverwrite_/opt/coldfusion2016/notice.txt=Yes

Summary
-------

Installation: Successful.

2612 Successes
0 Warnings
0 NonFatalErrors
0 FatalErrors

Action Notes:

None

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

OK, I have an update.  I added allowedRequestAttributesPattern=".*" to this line:

<!-- Define an AJP 1.3 Connector on port 8009-->
<!-- begin connector-->
<Connector connectionTimeout="60000" maxThreads="1236" packetSize="65535" port="8016"...

 

And now everything is working expected.  However, this obviously means I still have another issue that needs to be resolved and I am still confused why the version of Tomcat is different than the version you told me I should be seeing.  Just to make sure that the next secret key is actually being used, I went in and made the two keys not match.  Sure enough that made everything stop working.  So the keys are being used and everything is now at least working.

 

So my new question is first, are you 100% certain that the version should be 9.0.21 for Coldfusion 2016 level 14?  Since I have no errors regarding my upgrade, I don't understand why I would be on the wrong version.  And second, why adding  allowedRequestAttributesPattern=".*" has made everything start working and what I need to adjust to be able to remove that?

 

Thanks!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
Adobe Community Professional ,
Mar 21, 2020

Copy link to clipboard

Copied

Well, first, to be clear: NO, you CANNOT manually update Tomcat. Adobe bundles Tomcat under CF in a very customized way, and this is why we (using CF) have had to WAIT until this update for it to fix the problem that Tomcat 9.0.21 was said to fix (the ghostcat issue, mentioned in my blog post).

 

Second, I appreciate that you are finding this all very frustrating (and this is where most people would be cursing Adobe and CF, and panting for when they could get off of it). But I will tell you that I help with such frustrating problems daily, and there is always a solution. It is RARELY a "bug", and often not at all "Adobe's fault". I appreciate you are not saying that here. I'm just ranting a bit--and planting a seed for readers (and perhaps you, if it continues).

 

So, third, if I was sitting with you (providing remote consulting, trying to figure this out), I would be wanting double-check all you said. (It's so easy for httdp.conf files, and the files they include, and so on, to get very nested and hard to easily interpret. Consider that there are settings for all of Tomcat, then can be some set for a virtual host.)

 

And you may have more than one vhost, so tell us this: do you have more than one site? are ANY of your sites working?

 

If you have only one, then here's what I'd do next, to PROVE that the mod_jk.so that you say is "updated" is indeed the one that Tomcat's conf files are pointing to: rename it, and restart Apache. If you do, then do the requests which PREVIOUSLY worked (files that DO exist DO work, you said) still work? If they do, then clearly they are NOT using THAT connector (which you renamed), as Tomcat would not be able to find and load it. And that will tell us that you have some OTHER one that Tomcat is using.

 

Finding which it is using, again, will be challenging. One thing you can do is grep for that mod_jk.so file, to find any (in all folders on the server) that may exist, and then if there are not too many, try renaming them one at a time, and restarting Apache, and running the test (both tests). As you find that such a rename "does nothing", don't forget to rename the file BACK (including the first one renamed above).

 

There HAS to be an explanation. I am suspecting it's going to be that some combination of factors has you, Apache, and CF looking at some wrong combination of files, which explains where that Tomcat 8 reference in the error is coming from.

 

Let us know how that goes. Or if you decide not to, in which case I guess you can wait to see if someone has a better answer. It's not likely that Adobe will respond here. They generally do not (but occasionally do). You could ask for help from Adobe on the update blog post (that I point to in my blog post). I would NOT go into great detail there, but instead I would point them to this thread, so that they can read all you and I have offered, in case they may think of something else.

 

But I really would STRONGLY recommend you not do that until you have tried what I propose above. I really do think that sort of "process of elimination" is going to help you find where the problem/confusion is.

 

Once you find it, then you can focus on how it happened, and whether you may want to change things so that it does not happen again. (Indeed, it may be that you have been "upgrading" your CF web connector for a couple of years, thinking it was "working", when it is not.)

 

In fact, I just thought of one more thing you can consider: in that mod_jk.log you referred to originally, there should be a line whenever Apache restarts, reporting the connector version. In Windows, it's something like "Starting Tomcat/ISAPI/isapi_redirector/1.2.46". I don't have a Linux install readily available to check, but from looking around it may look like " mod_jk/1.2.46 initialized". The key question is what version number is that reporting for you? (I have found that it's NOT changed with this latest update, at least on Windows. But it may be that some process Adobe uses is not changing it always.)

 

My point is to see if yours is a very different reported version number, earlier than that. If it is, then it supports my contention above, and justifies all the more doing that process of elimination to find WHERE that connector is that Apache is using.

 

Let us know how it goes.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

Hey Charlie,

No rants from me about Coldfusion.  Though the years I have run into update issues with .net and java as well.  Just the nature of the beast.  Sometimes they go smoothly and sometimes you hit a snag.  Not sure if you saw I posted an update after my other post.  I now have things working after adding allowedRequestAttributesPattern=".*".  Now just have the two follow up questions that I listed in my last post.  I will repost here:

 

 So my new question is first, are you 100% certain that the version should be 9.0.21 for Coldfusion 2016 level 14?  Since I have no errors regarding my upgrade, I don't understand why I would be on the wrong version.  And second, why adding  allowedRequestAttributesPattern=".*" has made everything start working and what I need to adjust to be able to remove that?

 

Thanks again!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
Adobe Community Professional ,
Mar 21, 2020

Copy link to clipboard

Copied

Thanks, Jim. First, yes, I missed that earlier post. (Been jumping back and forth between this and some work.)

 

Second, great to hear that you solved it, with that allowedRequestAttributesPattern attribute--another facet of the fix for Tomcat for ghostcat (which this update addresses). Indeed, Adobe does discuss it in the technote for the update (though both that and the Tomcat docs are not too clear on when one should need to. It seems to be if/when something in the communications between your web server and CF sends unexpected attributes. I'll leave it to you and others to dig in further, if interested.)

 

And yes, I see now I was mistaken in presuming that an updated CF2016 would have the Tomcat 9 version. I forgot that Adobe only added support for Tomcat 9 in CF2016. But again, they DID indeed implement an updated Tomcat 8 connector in CF2016. And as you found, it DOES report 8.5.42 as of this update. I have corrected my comment above, and pointed to this comment for more clarification.

 

But finally, all this has pointed out something very surprising to me. That new allowedRequestAttributesPattern attribute, as well as the change of the secret attribute from requiredSecret to secret, and the change in the behavior about the address (all discussed in my blog post) are SUPPOSED to have been features introduced in a NEW tomcat version BEYOND these being reported by CF.

 

Again, currently for CF2018 it's reporting 9.0.21 (as I reported in my post) and 8.5.42 (as you reported--and I have not corrected in my post). But the version of Tomcat that was updated to fix that was 9.0.31 and 8.5.51, respectively!

 

So how is it that we (CF users) are NOT seeing our Tomcat version (reported in the CF Admin "settings summary" page) being that version, but instead these older Tomcat versions? In fact, I have confirmed that the "currently reported" Tomcat versions were introduced in Sep 2019 in CF2018 update 5 and CF2016 update 12, respectively (as confirmed in their technotes, linked there.)

 

Those "older" Tomcat versions do NOT support these newer attributes or the Ghostcat "fixes". So what gives?

 

The only thing I can conclude is that in these Mar 2020 CF updates, they did NOT update Tomcat, per se, but instead updated ONLY the Tomcat AJP *connector* (several tomcat files related to that). That's VERY interesting for me to realize (but I realize it's perhaps too deep int he weeds for most to care about).

 

Hopefully a later CF update really will get us to a later "real" Tomcat update (where all Tomcat-related files are updated, such as to 9.0.31 in CF2018, or 8.5.51 in CF2016.)

 

But for now, what matters for you is that you solved the problem. And I will add a mention of that additional attribute in my blog post, to call it out for others. And I will add a comment there also about this last point I have made about Tomcat not having been "completely updated". Some will want to know that.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
New Here ,
Mar 21, 2020

Copy link to clipboard

Copied

OK, well I really do appreciate your time on this and glad to know that I am on the correct version. Also, with your update to your blog regarding the additional attribute, hopefully that will help others that may run into this issue and save them a few hours of scratching their head. 😉

 

Enjoy the rest of the weekend.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
Adobe Community Professional ,
Mar 21, 2020

Copy link to clipboard

Copied

Thanks, and glad to help. This stuff is my daily exercise and mental workout! 🙂 

 

And FWIW I did add those two updated points to my post, right after writing here. I also added a comment to draw still more attention.

 

But fortunately the point about the attribute you had to add IS documented by Adobe in the update technote.

 

A challenge is that few read them, but as word spreads, people will be able more and more to help each other through this. Goes with the times, eh? 🙂

 

Until again. 

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2020 0
Adobe Community Professional ,
Mar 27, 2020

Copy link to clipboard

Copied

I can share an update on this: the problem Jim was experienging (as are others) is indeed down to the use of htaccess (and maybe also true for rewrites via mod_rewrite). The rewrite is adding a new header, in the request sent from Apache to CF--and thus the updated connector (in CF) fails the request for it not having one of the allowed (dozen) headers that are listed in the Tomcat docs (http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html).

 

And THAT is why Jim (and others) would conclude they have to use that regex value of ".*"  (for "anything"). I am working on determining if there's a way to add ONLY the extra header that is needed, rather than allowing "any" (which was indeed what the Tomcat fix was trying to prevent).

 

BTW, for anyone who wants to see WHAT header IS being sent in on requests that ARE sent to CF via a rewrite, you can see it, either of two ways. (Let me note that you can of course only see it when the request IS working, such as when you use that .* pattern, or if you roll back the update.)

 

One way is with the CFML function gethttprequestdata (or more specifically, coldfusion gethttprequestdata().headers). Another way is with FusionReactor, and its ability to see the "details" of a request, one of which is a "headers" tab. As I was working with one client, we found the header to be XSite-name.

 

And yes, we tried adding that as THE pattern. We did have to escape the "-" within the name, so "Xsite\-name". And that "worked" (in that now the "rewritten" site would run). And BTW, sites that were NOT being "rewritten" were working regardless. 

 

What's not clear from the Tomcat docs is whether in doing that, we are ADDING to or OVER-RIDING/overwriting the default values listed on the Tomcat doc page. Again, I plan to do some more research and testing on things. (I find virtually none by anyone else on the web.)

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 27, 2020 0
Explorer ,
Jun 10, 2020

Copy link to clipboard

Copied

I have worked other Apache related 403 error issues and I found using the servers IP and not localhost can also be the answer. 

  1. Edit ../#/workers.properties and change worker.cfusion.host from localhost to the server’s IP address
  2. Edit .../<instancename>/runtime/conf/server.xml and add address=”<ip address>” to the AJP connector line

Doing the above allowed the the connector and Tomcat\CF to communicate again.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 10, 2020 0
Adobe Community Professional ,
Jun 10, 2020

Copy link to clipboard

Copied

Yep, mcollins (Mike?). And I will note that I discuss that and still other possibilities (for errors after applying the March 2020 CF updates) in the blog post I linked to in my first reply above. Just adding that for still more consideration for amyone interested. There was a lot that happened in those updates, affecting settings in both those files. And that's what my blog post tries to relate, for those interested to know more.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 10, 2020 0