404 Handler loses FORM scope

2. Have I completely wandered so far down a dark pointless alley that I can no longer see the wood for the trees, and so have come up with a massively convoluted system which is far more complex than it ever needed to be?

 

I think you have.

However I'm now working on a site where it's very important, so went about creating a handling page which would catch *any* page, figure out what you meant and using getPageContext().forward() to get the actual content. I've always known the theory behind doing so, but have never really gotten this far into the gubbins of it all.

I'm not sure I quite follow.

Are you saying you're going to have a URL like http://www.owain.co.uk/some/path/to/a/file.cfm and you are going to 404-handle it, and redirect it to http://www.owain.co.uk/index.cfm which is then gonna look at the /some/path/to/a/file.cfm and work out that you need to include x.cfm, y.cfm and z.cfm etc?

You don't want to be doing that with a 404 handler.  You want to be doing it with mod-rewrite (or isapi_rewrite, or whatever).

Get the web server to route the SEO friendly URL to the correct CF-ready URLs.  don't get CF to do it.

--

Adam

Yep, well in that case it's def a job for mod_rewrite.

--

Adam

mod_rewrite does a few things, the relevant two are:

* redirects one URL to another (by, like, doing a 301 redirect).  Not what you want in this situation

* rewrites a URL internally, which is exactly what you want.

Say you have URLs thus:

http://www.owain.co.uk/product/1234/

You could have a rewrite thus:

RewriteRule ^/product/([0-9]+).*$ /index.cfm?product=$1

The web server will then treat the URL as /index.cfm?product=1234, which gets passed on to CF because it's a CFM page (in the way it normally would).  The client doesn't see any of this, and is none the wiser.

mod_rewrite (and its isapi counterparts) is very powerful & flexible, and has very little overhead.

--

Adam

I'd never used mod_rewrite (or in our case Helicon's ISAPI version) until my current job, at which I've been for four months or so now.  But because I'm reasonably good with regexes, I've kind of inherited the management of our .htaccess files.

A coupla tips that might be handy for a newbie to save you the pains I went through:

* investigate rewrite maps from the outset.  They're bloody handy.

* when one has a RewriteRule and a bunch of RewriteConditions, eg:

RewriteCond TestString CondPattern
RewriteCond TestString CondPattern
RewriteCond TestString CondPattern
RewriteRule Pattern Substitution

Despite how it looks, the RewriteRule PATTERN is processed first, and then each of the conditions from top to bottom, and then finally the Substitution.  It's not logical and it's also not immediately apparent from the docs (well at least my reading of them).  Processing will stop for that rule as soon as a pattern doesn't match.

* A rewritemap substitution can only be used in Substitutions and TestStrings.  Not in Patterns or CondPatterns.

* In at least Helicon's implementation, one cannot have a comment on the same line as a RewriteMap statement, eg:

RewriteMap mapLabel txt:mapfile.map # some helpful comment here

On any other line, one can comment like this NP.

HTH.

--

Adam

From what little exposure I've had to it IIS7's rewriting ain't bad.  I think one needs to create the rules via the UI though - rather than use a .htaccess file - which might limit its flexibility, but for the stuff you're needing to do it'd do just fine.

--
Adam

Cool.  No worries mate.

--
Adam