Possible bug upgrading from 1.6 to 1.8 RC1

[Matthew]

Hi guys

SHORT VERSION:
I don't think 1.8 RC1 supports the following property which may be a
bug or a bad way to construct urls (but accommodated by 1.6);
<property name="urlDelimiters" value="/|&amp;|=" />
This translates to something like "/index.cfm/event=..."

LONG VERSION:

I'm experimenting with upgrading from 1.6 to 1.8 RC1. I ran into a
problem where after many hours of investigation I found that my app
(in 1.8) was returning the default event instead of the event which it
should have been. After much digging around in the MachII code base
(and not realising that I could have saved a lot of time if I knew
about logging) I found that perhaps the way I was ReWriting urls was
guilty. However it did work in version 1.6 so I thought I'd throw it
out in case it is a bug.

Before I get to showing my URLs I just wanted to point you to the line
of code in 1.8 RC1 which after many hours of digging is where I found
to be the issue causing the default event to be returned because my
event in the CGI.PATH_INFO was being ignored (it appears if I'd have
enabled logging I'd have found it much sooner - I've learned for next
time). The line of code is /framework/RequestManager.cfc line 412-414.
I've given up trying to interpret this error on line 413 "Could not
find a configured url route with the url alias of '#names[1]#'. Routes
can only be announced from the browser url using url alias. Route
names are only used when referencing routes from within the framework
such as BuildRouteUrl(). Cleaned path_info='#arguments.pathInfo#'".

Now to my urls. As mentioned above I setup MachII to accept urls as:
<property name="urlDelimiters" value="/|&amp;|=" />
This was to accommodate my urls which were Isapi ReWritten as" /
index.cfm/event=...". Note the ".cfm/" instead of ".cfm?"

To solve the problem I have removed the <property name="urlDelimiters"
value="/|&amp;|=" /> and reverted back to good old correct urls i.e. "/
index.cfm?event...". After doing some reading I believe that urls
written the way I was doing them is invalid anyway which is why I am
not flagging this as a bug.

Right: enough time wasted, back to what I was doing.

By the way: thanks MachII team for a great framework!

Cheers
Matthew

[Peter J. Farrell]

Matthew,

Thanks for the information. I have a few thoughts for you.

* I wouldn't encode the &amp; in urlDelimiters. Mach-II takes care of
UrlEncoding all build URLs for you. Since the 2nd parameter has more
than one character -- I'm pretty sure this could be problem decoding any
SES urls. I bet if you set the property to "/|&|=" things would clear up.

* Did you have urlParseSES property set to true/false? If you are
willing to have index.cfm in the URL, Mach-II will do the path_info
parsing for you when urlParseSES is set to true. There is no need to
use ISAPIRewrite in that case.

* What was the value of the urlBase property? If you have a relative
path (one that doesn't start with "/"), SES URLs will become all mucked
up. It's not a Mach-II problem, but how browsers pass information to
the webserver. You'll end up with URLs like
index.cfm/event/home/index.cfm/event/aboutUs/ etc. where the browser
starts pilling up parameters on the old URLs.

Let me know how things work out.

Best,
.Peter

Matthew said the following on 12/09/2009 01:40 AM:

[Matthew]

@Peter: thanks for the feedback, here are my answers to your comments:

1. I replaced "&amp;" with "&" and get the following error which is
probably why I had "&amp;" from when the app was first built.
ERROR
Exception occurred parsing base config file 'C:\Inetpub\wwwroot\project
\configs\mach-ii.xml' for module ''.
Type: Expression || Message: An error occured while Parsing an XML
document. || Detail: The entity name must immediately follow the '&'
in the entity reference. || Original Template: C:\Inetpub\wwwroot
\MachII_1-8-0_RC1\MachII\framework\AppFactory.cfc at line 133

2. I did have the urlParseSES property set to true. I don't want
"index.cfm" in my URLs because I want my URLs to appear as if it was a
flat website i.e. /folder/folder/page.htm. I guess you could argue
that /index.cfm/ is the 1st folder however I just don't like having it
there, plus I feel it degrades SEO because the spider would see
content as being an extra folder deep in the app so less relevant.

3. I don't have a urlBase property set. But I have run into the
problem you speak of with parameters being piled up on each other. Now
I always use absolute urls i.e. "/..."

As mentioned above I have found a fix so don't waste your time
investigating for my benefit however I'm happy to keep digging if you
think this is a bug or upgrade querk.

Cheers
Matthew

[Peter J. Farrell]

Inline

Matthew said the following on 12/09/2009 03:56 PM:

@Peter: thanks for the feedback, here are my answers to your comments:

1. I replaced "&" with "&" and get the following error which is
probably why I had "&" from when the app was first built.
ERROR
Exception occurred parsing base config file 'C:\Inetpub\wwwroot\project
\configs\mach-ii.xml' for module ''.
Type: Expression || Message: An error occured while Parsing an XML
document. || Detail: The entity name must immediately follow the '&'
in the entity reference. || Original Template: C:\Inetpub\wwwroot
\MachII_1-8-0_RC1\MachII\framework\AppFactory.cfc at line 133
  

Well, you'll need to use an XML entity to use the "&" character in XML.  I guess &amp; works ok.

2. I did have the urlParseSES property set to true. I don't want
"index.cfm" in my URLs because I want my URLs to appear as if it was a
flat website i.e. /folder/folder/page.htm. I guess you could argue
that /index.cfm/ is the 1st folder however I just don't like having it
there, plus I feel it degrades SEO because the spider would see
content as being an extra folder deep in the app so less relevant.

3. I don't have a urlBase property set. But I have run into the
problem you speak of with parameters being piled up on each other. Now
I always use absolute urls i.e. "/..."
  

Yep, you'll need "/" in there.  UrlBase shouldn't ever be set to "" unless you want relative URLs.

As mentioned above I have found a fix so don't waste your time
investigating for my benefit however I'm happy to keep digging if you
think this is a bug or upgrade querk.
  

Probably not a buglet -- just a side effect of configuration and URL rewriting.  We can't change how browsers handle URLs and not all combinations of URL delimiters will work.

Thanks for letting us know about the configuration issues.

.Peter