Just tried breaking out the 404 code into a dedicated 404 handler,
rather than using a combined file.  No luck.

Also, I mapped the web root of the web site in the CF Admin.  Then I
placed the 404 handler in the web root and confirmed it was working
(so that means that CF mappings work inside the administrator itself).
 However, when I put in the cfinclude code it promptly broke the
handler.  In this case, the 404 handler and the included file were
both in the same folder - the web root.  Same file not found error. 
After that, I prepended the mapping in front of the cfinclude.  Again,
file not found.

That seems to be a bug in CF.  If you have CF set up so that its own
web root is not shared by your web sites, you cannot use cfinclude to
traverse across folders -- specifically different branches, whether
you use mappings or not.

I cannot verify if this bug exists if you have set up IIS to have the
web root the same as CF's default, but since you have the freedom to
choose your own web roots via IIS (and arguably for security's sake
you should always do this) this appears to be a way to break some of
CF's functionality.

On 12/22/05, Matt Robertson <[EMAIL PROTECTED]> wrote:
> On 12/22/05, Mosh Teitelbaum <[EMAIL PROTECTED]> wrote:
> > Perhaps you have some other code problem in the 404 handler?
>
> Nope.  My 404 handler is also my site wide error handler (you can just
> specify both as the same template in the CF Admin).  It starts like
> this:
>
> <cfif not isdefined ("error.diagnostics")>
>    <cfset variables.GoPage="http://"; & CGI.SERVER_NAME>
>    <cflocation url="#variables.GoPage#" addtoken="No">
> </cfif>
>
> Given the subject of this thread, I have expanded that code, whose
> purpose above is simply to kill linkrot.  Code from that point onward
> is site wide error handler-related.
>
> If you do ANYTHING wrong in a site wide error handler, CF defaults to
> raw CF error messaging... with no clue as to what the error was in the
> handler.  If the code wasn't sound CF would happily explode with a raw
> error that flags the original error, not the one thrown by the handler
> (which you have to debug on your own... been there, done that).
>
> --
> --mattRobertson--
> Janitor, MSB Web Systems
> mysecretbase.com
>


--
--mattRobertson--
Janitor, MSB Web Systems
mysecretbase.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking 
application. Start tracking and documenting hours spent on a project or with a 
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:227563
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to