Skip navigation
Currently Being Moderated

Default document not being processed when not included in URL

Nov 1, 2012 1:32 PM

Tags: #install #coldfusion #coldfusion9 #cf9 #connector #webserver

Running ColdFusion 9,0,1,274733 on JRun (J2EE install), Windows Server 2008 R2, Java 1.6.0_22

 

Has anyone else had a problem getting the default document, index.cfm, to work with ColdFusion? I'm assuming that this is only an issue because of our setup; different web server (IIS) and application server (ColdFusion). I can't imagine we are the only ones running this configuration. Are we?

 

So here is the issue.

If we request http://mysite.com/test/index.cfm it works.

If we request http://mysite.com/test/ it does not work and we get a 404.

 

I checked the web connector's log file on our IIS server and can see that it is sending the request to our ColdFusion server. The ColdFusion server is sending back the 404 error code but I can't figure out why. We have the default document set on our IIS server for index.cfm. We also have the <welcome-file-list> set to include index.cfm on our application server (web.xml).

 

 

From our web connector's log when we do NOT include index.cfm:

 

2012-11-01 13:37:22 jrISAPI[4544:3600]  ***HttpExtensionProc for JRun ISAPI Extension: uri is "/test/"

2012-11-01 13:37:22 jrISAPI[4544:3600]     HTTP_HOST: servername

2012-11-01 13:37:22 jrISAPI[4544:3600]  filtering /test/ (/test/) HOST=servername

2012-11-01 13:37:22 jrISAPI[4544:3600]  filterRequest:   no match

2012-11-01 13:37:22 jrISAPI[4544:3600]  ExecUrl: request received: URL=/test/

2012-11-01 13:37:22 jrISAPI[4544:3600]  ExecUrl Completion: 404, ErrorCode=2, URL=/test/.

 

From our web connector's log when we do include index.cfm:

 

2012-11-01 13:49:02 jrISAPI[9936:3600]  ***HttpExtensionProc for JRun ISAPI Extension: uri is "/test/index.cfm"

2012-11-01 13:49:02 jrISAPI[9936:3600]     HTTP_HOST: servername

2012-11-01 13:49:02 jrISAPI[9936:3600]  filtering /test/index.cfm (/test/index.cfm) HOST=servername

2012-11-01 13:49:02 jrISAPI[9936:3600]  filterRequest:   matched *.cfm

2012-11-01 13:49:02 jrISAPI[9936:3600]  ***IISWorkerThreadProc for JRun ISAPI Extension: uri is "/test/index.cfm"

2012-11-01 13:49:02 jrISAPI[9936:3600]     ALL_RAW: Connection: Keep-Alive Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, application (553)

2012-11-01 13:49:02 jrISAPI[9936:3600]  Headers and Values:

... and much more ...

 

We have gotten around this issue by using the URL Rewrite module in IIS to append index.cfm to the URL. It works but my gut keeps telling me that we should not need to do that for such basic functionality.

 

Is anyone else having this issue? How have you gotten around this?

 
Replies
  • Currently Being Moderated
    Nov 1, 2012 2:03 PM   in reply to Miguel-F

    If you are using IIS, index.cfm is not in there by default.  You have to add it to the default documents list.  I don't have instructions, for that, but it's easily googled.

     

    Never mind.. didn't read the whole post. 

    ^_^

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2012 2:21 PM   in reply to Miguel-F

    First, Miguel, by “ColdFusion on JRun (J2EE install)”, do you really mean you deployed a CF WAR on JRun? Or do you mean you chose the Multiserver form of deployment of CF, which does also deploy CF on JRun (but not as a WAR)? May not be critical, but since you wonder about how unusual your setup may be, it seems worth clarifying.

     

    In fact, you go on to say you wonder if it’s “only an issue because of our setup; different web server (IIS) and application server (ColdFusion)”, but nearly everyone runs CF with a web server separate from CF. You don’t mean the web server is on one box and CF is on another (what has traditionally been called “distributed CF”), do you? If so, that would be unusual, but is indeed still supported (if horribly documented).

     

    Back to the default document, I see you saying you set the default document in IIS, but doesn’t the log suggest it was NOT being passed in from IIS to CF?

     

    Is it possible that you have it set in a web site other than that which this request is going through? If you may say “no”, here’s something else to consider: if this is IIS 7, running in native (not IIS 6 compatibility) mode, did you realize that settings made in IIS are saved to a web.config file in the docroot? I’ve seen people get in trouble when they have 2 sites sharing the same docroot, and someone changes settings in one site, not realizing that that causes changes to the other site (literally, you would see it reflected in the IIS interface). So do check to make absolutely sure that index.cfm is in the docroot (just before you make the test request).

     

    Also, since you mention using rewrite rules, is it not possible that one of those rules is getting in the way? Try disabling that functionality for a moment and retry the test request.

     

    Finally, here’s an outside the box thought: are you absolutely positive that the request you’re making is going through that site? You could have a request being unexpectedly handled by a site other than what you think. It’s possible, but I realize not likely.

     

    Hope that helps some. If not, just say so and perhaps others will have more ideas.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2012 3:25 PM   in reply to Miguel-F

    Thanks for the clarifications, Miguel.

     

    - So to be clear, you don’t want to say you’re doing a “J2EE install”, for future reference. That is very different from multiserver (there are 3 choices on CF install: server, multiserver, and J2EE).  I do appreciate that technically the multiserver deployment is an install on a J2EE server (JRun), but then so technically is server (it’s just more hidden). If you were doing that third, WAR/EAR deployment, that would indeed be far less typical than most do.

    - As for doing distributed mode, ok that’s interesting. That is also indeed atypical. But I don’t think it should affect this issue. I’ve never done it, though, so I can’t say for sure.

    - As for the default document/welcome-file-list in CF, that’s for use with the built-in web server, so should have no bearing in this discussion. (Again, I understand that it would not be clear on the surface)

     

    Now let’s move on to more practical matters:

    - You say, “I have disabled the rewrite rules for this test.  With the rewrite rules it works.  It just seems like that should not be necessary.” Did you really mean to say “without the rewrite rules it works?? If so, then what “should not be necessary”? It would seem the rewrite rules could then explain what’s happening, if they are somehow passing the request on to CF before IIS would detect that it was missing a default document. (You may want to explore the modules/filters/other pages in IIS where there is an option to change the ordering of things. Maybe something is handling the request before the default document processing happens.)

     

    Finally:

    - I had asked, “are you absolutely positive that the request you’re making is going through that site”. Your answer to that seemed to suggest you thought I was asking something else. But bottom line, in that you said (earlier in your note) that you have only the one web site, that rules out my point there.

     

    Hope something clicks for you.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 2, 2012 6:41 PM   in reply to Miguel-F

    Yep, the external web server connector would indeed refer to the web.xml. It looks at its indications for which file extensions CF should use.

     

    (CF Bar bet: many people think it’s the handler mappings in IIS that control what extensions are passed to CF, but that’s not so. Indeed, those are really more a “vestigial tail” in the body of CF, leftover from the way that things used to be done in IIS 5, before IIS6 added the “wildcard mapping” feature, so that technically now all requests for all extensions are indeed passed to the web server connector, and it checks to see what extensions CF says it wants to handle.)

     

    As for your observation that you need the rewrite rule, ok. But I’m asking: what if you disable all IIS rewrite rules? I just wonder if perhaps some other one you have may be getting in the way here. If you’re saying you’ve done that, and that the ONLY difference between this server and the one where you are not using distributed mode, then I agree it would seem that’s the cause. I just have no experience to say, but I will say that I’ve also not heard that ever reported as a “problem” with distributed mode.

     

    Finally, as for your last point, that is interesting, and yes, as discussed above (which I wrote before I got to the bottom of your note), that would indeed cause CF to try to process all file extensions, which you would not want. But it begs a question: why would adding THAT make things now suddenly work? If the default document is passing in index.cfm, it should be handled by the existing web.xml declaration for *.cfm.

     

    So something definitely seems very odd with your setup. Since I have no experience with distributed mode, I think I will have to bow out as I have nothing more to add. Let’s hope that perhaps Steven Erat (who frequents this forum and does have lots of experience with distributed mode) might chime in eventually for you.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 2, 2012 6:47 PM   in reply to Miguel-F

    Miguel, that web.config definition of the defaultdocument looks ok, of course. But it made me think of a couple of other things:

     

    - first, have you confirmed that a default index.htm file is also found and executed? If you put one in the docroot, and change the iis “default document” settings page for the site so that the index.htm is listed in order above index.cfm? It just seems worth making sure that this is really a CF problem after all. It could instead be IIS not running any at all.

    - along those lines, on that “default document” settings page for the site, note in the top right corner there is an “enable” or “disable” link. Does yours say “enable”? If so, the feature is disabled. (Note that I am NOT referring to when you have selected a given default document (whereby you also see “move up” and “move down” options on the right), but rather when you first come into that page.

    - also, look in the modules page for the site and confirm that you see a DefaultDocumentModule listed.

     

    Hope that helps.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 3, 2012 11:43 AM   in reply to Miguel-F

    Yep, good point on a possible implication of Win2k8’s tighter security.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 3, 2012 11:44 AM   in reply to Miguel-F

    Well, without studying things more I’m just speculating, but it seems to suggest that it’s just not doing the default document at all, so checking into those settings on Monday may be the answer, but maybe not. Looking forward to seeing what you find.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 5, 2012 7:34 AM   in reply to Miguel-F

    Good to hear you may be on the trail. I don’t have any machine set with “distributed CF” setup to test things, but perhaps others will.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 5, 2012 9:49 AM   in reply to Miguel-F

    Hey Miguel, just one quick observation: the CF Admin mappings have absolutely no connection at all to processing of URLs against CF.  That is entirely down to mappings in the web server, The CF admin mappings are only used for file references within CFML, generally by things like cfinclude, or invocation of CFCs with cfinvoke/cfobject/createobject, and so on.

     

    So I’d be very surprised if there’s any connection with your problems and the mappings. Indeed, I’d think any such impact would reflect more a problem of failures of CFML processing, rather than failures in communication between the web server and CF. Hope that helps.

     

    BTW, I’ve put word out to see if some other folks interested in this topic (of “distributed mode”) might be able to take a few minutes to chime in if they may help.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 5, 2012 12:20 PM   in reply to Miguel-F

    Miguel, a few more thoughts.

     

    First, about your last paragraph, that page you point to in the manual does not discuss distributed mode. Did you mean another page? If you are referring to its point 9, that’s not about distributed mode, either. That’s about the fact that even once you configure CF to use an external web server, it still does refer to the webroot for CF’s internal web server when processing CFM pages (a surprise for many) and it’s referring to how it does NOT do that for static pages (once you stop using the built-in web server, which is what the page is about: switching from the internal to an external web server.)

     

    As for the CF docs still discussing distributed mode, I’ll argue that in fact they do not. I was discussing this in fact with Adobe (and some other folks, including Steven Erat), where I noted that  the CF install manual (9 and 10) says "For more information on the Web Server Configuration Tool, including information on multihoming and distributed usage, see the Configuring and Administering ColdFusion guide." But then that manual (in 9 and 10) makes no reference to "distributed" at all, though it does have a section on "multhoming" (but it makes no mention of running CF and the web server on different boxes).

     

    It really feels like the reference was dropped at some point. Steven concurred and we hoped that someone from Adobe might pick up that ball and run with it. (Steven no longer works on the CF team, though he is back to working at Adobe.)

     

    Finally, about the lockdown guide, I wouldn’t say it “recommends distributed mode”. It mentions it as “something you might also consider”. But it too points just to those old CFMX-era technotes.

     

    Steven had also agreed that much more updated info would be beneficial, and he was thinking of doing more on that (whether on his own blog or perhaps as a contribution to the CF docs.) I’ve not heard more about that for a while, though. I look forward to whatever he may do. HE’s a really valuable resource for the CF community.

     

     

     

    And again, I’ve asked him if he might be able to chime in here at some point.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 5, 2012 12:29 PM   in reply to Miguel-F

    Ah, ok, it may. I was indeed looking for that phrase, and in not finding it, read the page but missed that point.

     

    Again, I don’t have any experience with DM to be able to say if that’s referring to that. Sounds like it. You have more experience on that than me. Would you say so?

     

     

     

    /charlie

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points