Lucee, IIS, and Mura w/ FW/1 - URL Rendering Not Working Correctly

I heard back from BlueRiver last week, they said they are setting up an environment to test and see if they can figure it out. We’ll see what comes to that.

In the meantime, I have come up with two workarounds. I am not super excited about either. I would rather it just work correctly, but, if needed, I could potentially implement one of the workarounds.

Workaround #1
The first workaround is to pass the path with the calls to buildURL() redirect(). This seems to accomplish what I need.

Example:
<form action="#buildURL('main.saveGraduationRequest', '#cgi.path_info#')#" id="graduationForm" method="post">

Note the additional cgi.path_info param being passed in.

Unfortunately, this workaround would require HUNDREDS of code changes. Going forward, if I develop new plugins, I will use this method.

Workaround #2
The second workaround is to modify FW/1 itself.

In the buildURL() function, if I replace this line:

path = pathData.path;

with:

path = cgi.path_info

It seems to correct the problem.

I have not determined if there are any other consequences to making this change. Fortunately, each plugin has its own copy of FW/1 and the only thing that copy of FW/1 does is support that plugin. So, if the plugin works correctly with the change, it should not affect anything else.

Like I said, I’d rather it just work correctly. I am still open to ideas if anyone has any.

Hi,

The Workaround #1 is way too much work and too much hardcoded. If the original issue is fixed later, it will require going through all the files again.

The Workaround #2 is interesting. Instead of changing the buildURL, take a look at resolveBaseURL (buildURL use it). Maybe it’s a better place to change the behavior? Look at this line :

} else if ( path == 'useRequestURI' ) {
            path = getPageContext().getRequest().getRequestURI();

If getPageContext().getRequest().getRequestURI() is empty, I would change it to use cgi.path_info instead. But since the two variables don’t return exactly the same thing, I would be very careful before implementing this and I would do a lot of tests.

As I have never used FW/1 or Mura, I don’t know either if it can have unwanted side effects. But it could be an interesting solution in the short term until the original issue get fixed.

And instead of paying $10,000 for an Adobe Coldfusion license, you could pay a consultant to solve your problem. It would cost less.

I did some more digging and comparing.

First, after years of using the Mura FW1 plugin I never noticed the it overrides buildURL() and redirect() in its Application.cfc. Part of that override includes a call to a resolvePath() method within the App.cfc.

That resolvePath() method uses getPageContext().getRequest().getPathInfo() which returns /index.cfm in Lucee, but in ACF it returns /graduation/apply/index.cfm (the index.cfm is subsequently stripped out in both).

So there is where I find the difference between Lucee and ACF (at least while in Mura).

As I said, I have been using these plugins for years, and while I have updated Mura and updated FW/1 over the years, I have never bothered to look at the App.cfc to see if it needs updating.

I see in the git history that at some point Steve updated the MuraFW1 plugin’s App.cfc with much simpler code for that resolvePath() method that no longer uses getPageContext().getRequest().getPathInfo(). Instead, it just returned “./”, which seems to work.

public string function resolvePath() {
return './';
}

Now, instead of getting “/” back in Lucee and “/graduation/apply/” in ACF, I get “./” back in both. This seems to work. It puts the responsibility of where to direct the form POST on the browser instead of having the server try to figure it out from the PageContext.

I don’t know if Steve made this change because of the way it works in Mura with Lucee or if it was just simpler, or for some other reason, but that may be all I need to do.

The best part, so far, is this then does not require changing FW/1, Mura, or making hundreds of changes in my code.

1 Like

Good sleuthing, Jason. I had faith you’d find a solution. :slight_smile:

Sadly, it involved a combination of moving parts not used so widely. But you’ve contributed helpfully now to that subset of folks!

And along the way your experience could serve as a model for some, in sticking with a problem on your own to get to its solution. Some situations will simply demand that, though I realize not everyone will be up for the challenge.

So glad you solved the mystery!