Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Linux (CF-Linux)
Odd 500 apache/Jrun/ColdFusion error
Author: Terry Ford
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4565
Bit of a puzzle here...
If a user calls any URL of the form "*.cfm.*" on my server (existing or not), I
get a 500 error.
Example:
http://my.site.com/index.cfm.html ,or
http://my.site.com/index.cfm.spaghetti
Error displayed to user is an "Internal Server Error". In apache error_log
there is the message "JRun will not accept request. Check JRun web server
configuration and JRun mappings on JRun server." Nothing in any CF logs.
My httpd.conf handler is the default:
AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf
My question is... why is JRun trying to handle this file? None of these
examples END in .cfm, so surely apache shouldn't be handing them off to Jrun?
It should be issuing a 404, not a 500.
Does anyone have any idea where the problem might lie? This is happening on both
CF8 and CF9.
Thanks
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4566
----- Excess quoted text cut - see Original Post for more -----
Actually, the JRun module processes all requests, whether they
correspond to an extension that's mapped in httpd.conf. If they
correspond to an URL pattern listed in web.xml, they'll then be passed
to the CF server proper. That said, I'm not sure why it's causing an
error in the JRun module. You might look at the patterns you have
listed in web.xml.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
http://training.figleaf.com/
Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on
GSA Schedule, and provides the highest caliber vendor-authorized
instruction at our training centers, online, or
Author: Terry Ford
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4567
Hi Dave,
Wow, I never realized that Jrun looked at every HTTP request. Isn't that the
whole point of AddHandler? To tell Apache what file types to hand off to Jrun?
Do the "AddHandler" statements do anything then?
I turned Jrun verbose mode on and yep, every gif, html, cfm, and non-existent
file is being passed through to Jrun...
Jrun handling "star.gif":
[Fri May 13 17:58:44 2011] [notice] jrApache[7365: 46824] HOST: www.host.com
[Fri May 13 17:58:44 2011] [notice] jrApache[7365: 46824] filtering /star.gif
(/var/www/html/star.gif) HOST=www.host.com
[Fri May 13 17:58:44 2011] [notice] jrApache[7365: 46824] filterRequest: no
match
[Fri May 13 17:58:44 2011] [notice] jrApache[7365: 46824] jrun_service: r is
0x7303b6b8, server is 0x6fda1b70, virtual 1
[Fri May 13 17:58:44 2011] [notice] jrApache[7365: 46824] jrun_service: no
handler, return DECLINED
Now it handling the bogus "a.cfm.html":
[Fri May 13 18:00:44 2011] [notice] jrApache[7361: 48360] HOST: www.host.com
[Fri May 13 18:00:44 2011] [notice] jrApache[7361: 48360] filtering /a.cfm..html
(/a.cfm.html) HOST=www.host.com
[Fri May 13 18:00:44 2011] [notice] jrApache[7361: 48360] filterRequest: no
match
[Fri May 13 18:00:44 2011] [notice] jrApache[7361: 48360] request not for JRun.
[Fri May 13 18:00:44 2011] [notice] jrApache[7361: 48360] JRun will not accept
request. Check JRun web server configuration and JRun mappings on JRun server.
Weird that the second request is treated differently than the first, when they're
both "no match".
Strange that it's not passing through a 404 though, since "a.cfm.html" does not
exist.
I found a bunch of sites out there that show this same behavior, so it looks like
it's pretty common in linux/apache setups. As long as there are no exploits or
anything it's no big deal. I just get a little nervous when documents get
handled inconsistently. A document that does not exist should throw a 404, not a
500.
Terry
----- Excess quoted text cut - see Original Post for more -----
or
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4568
> Wow, I never realized that Jrun looked at every HTTP request. Isn't that
the whole point of AddHandler? To
> tell Apache what file types to hand off to Jrun? Do the "AddHandler"
statements do anything then?
Well, I'm not entirely sure if they do anything. I'm not as familiar
with Apache internals as I am with IIS.
Here's how things work in IIS: when you install the web server
connector, it configures an ISAPI module (much like an Apache module,
I guess) that hooks into the IIS processing pipeline in two places -
at the very beginning (an ISAPI filter) and at the very end (an ISAPI
extension). The filter passes all requests to JRun regardless of the
URL pattern, and then JRun accepts or rejects them based on the URL
patterns it's configured to use. If JRun rejects the request, it gets
passed back to IIS for normal handling. The ISAPI extension, on the
other hand, is only invoked based on specific file extensions. By
default, both would be configured, but there would be specific
use-cases where you might choose to disable the filter (by enabling
the "check that file exists" option in IIS which requires that IIS
itself process the file first, for example). Disabling the filter
would also cause some features not to work, as some "magic" URL
patterns that CF executes don't actually exist (/CFIDE/Main/ide.cfm
for RDS, the URL patterns for CFCHART and CFIMAGE, etc).
At least, this is how things used to work in IIS - it's a bit
different now, as CF installs an ISAPI wildcard extension instead of a
filter. But the wildcard extension, like the filter before it, sends
all requests to JRun.
So, assuming that the filtering functionality is working in Apache, my
guess is that the AddHandler statements aren't doing anything for
those requests.
This is why some people configure CF to have a context root other than
"/". For example, on the Adobe site, CF files all have this URL
pattern somewhere within the URL: "/cfusion". That's the context root.
By having this non-standard context root, the web server can directly
process any URLs without that pattern. This will improve performance -
not that much, as far as I can tell, but a little.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
http://training.figleaf.com/
Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on
GSA Schedule, and provides the highest caliber vendor-authorized
instruction at our training centers, online, or
onsi
Author: Terry Ford
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4570
Thanks for the explanation, Dave. It appears on linux at least the JRun
pre-filter is detecting *.cfm* as being a CF file, and then somewhere else
(perhaps in the post filter?) determining that it's not and throwing an error..
In the end it doesn't really matter. One nice side effect is that if you
accidentally save a file as test.cfm.save (or any other temporary extension), it
cannot be read by the server in cleartext.
Terry
----- Excess quoted text cut - see Original Post for more -----
onsi
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-linux/thread.cfm/threadid:1122#4571
> Thanks for the explanation, Dave. It appears on linux at least the JRun
pre-filter is detecting *.cfm* as being a CF file, and then somewhere else
> (perhaps in the post filter?) determining that it's not and throwing an
error..
I suspect that the "somewhere else" in this case is the CF server
itself. You can probably fix this by editing web.xml to have more
specific patterns - maybe you want to execute:
*.cfm$
*.cfm?*
*.cfm/$
In the above examples, I'm using a dollar sign to denote the end of
the string - I don't know if that syntax is supported in web.xml
offhand, though. I was a bit curious about what kind of patterns you
can use in web.xml, and found these two links which would help me
figure out the answer if I cared enough to look:
http://schemas.stylusstudio.com/j2ee14/n562c1ad0/complexType_url-patternType.html
http://www.coderanch.com/t/414165/Servlets/java/url-pattern-web-xml
(describes differences between Servlet API versions, not really that
relevant as far as the patterns themselves go)
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
http://training.figleaf.com/
Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on
GSA Schedule, and provides the highest caliber vendor-authorized
instruction at our training centers, online, or
onsite
|
May 19, 2013
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
