Forms not posting when using FURLs and setting 404 & 405 to /index.php

Hi All,

I’ve renamed the subject of this post following further investigation. Turns out I have exactly the same issue Onesmarthost had back in 2006: http://modxcms.com/forums/index.php/topic,3670.0.html. I removed my MODx Evolution v1.0.2 install and added v1.0.3 instead but still have the issue both with weblogin and the standard contact form that comes with the default install.

Can anyone suggest what I need to look at to resolve this as I’m out of ideas right now.

Original post is below for reference.

Thanks.

---

I have MODx Evolution v1.0.2 installed on Windows 2003, IIS 6 with ISAPI_Rewrite v3 and PHP v5.2.6 Fast CGI /MySQL v5.0.45. The installation is pretty much as it was out of the box with the only changes being made as I work my way through the MODx Web Development by Antano Solar John.

I have FURLs working nicely with ISAPI_Rewrite but have an issue when it comes to logging in as a web user. I can login no bother on the default Home Page [id=1] but cannot login from any other page. If I turn FURLs off I can login on any page as you would expect.

I’ve tried almost every combination for Friendly URL Prefix/Suffix, FURL Alias and Alias Path etc. but still cannot login as a Web User from anything other than the Home Page.

I have Live HTTP Headers installed on Firefox and can see the login Form POST data is being sent to the the page successfully.

The WebLogin snippet is uncached as are the pages I’m trying to login from.

I have the base path set in all templates: <base href="[(site_url)]"></base>

The only thing I can find through searching the forum is: http://modxcms.com/forums/index.php/topic,3670.msg26550.html#msg26550 but it seems to suggest a hack rather than a solution. It does work for me though if I prefix the FURLs with: index.php?q=

Can anyone suggest what I might start looking at in order to resolve this?

Thanks,

Chris

Turns out IIS 6 is not maintaining the POST data when 404 and 405 Custom Error Handlers are set. I should have read http://modxcms.com/forums/index.php/topic,3670.msg26550.html#msg26550 more slowly as it is discussed there.

Hi Chris,

We have seen this problem in the past and its more to do with the ISAPI Rules being incorrect or ISAPI Rewrite driver not loaded on the actual website.

As a test enable friendly URL’s in MODx, and for the website reset the custom error page to the default setting for 404 instead of /index.php

Now if the ISAPI Rewrite is not working you should get an IE 404 Error page.

Which version of ISAPI Rewrite are you using?

Aaron

Hi Aaron,

I’ve decided that ISAPI_Rewrite is working correctly and it is IIS 6 that is causing the issue by not passing the POST variables to the 404 page.

I’ve put a workaround in place to test which seems to be doing the job but I started a new topic to see if anyone could advise of anything that may be unsuitable for what I have done as it does rewrite one of the global variables.

Take a look at: http://modxcms.com/forums/index.php/topic,48176.0.html

Thanks!

ps. my apologies for the slow response, I didn’t realise ’reply notifications’ had to be enabled manually.

Hi Chris,

I can fully say with 100% past experience the problem was that ISAPI Rewrite was not working and IIS was just doing the friendly URL stuff based on the custom error page being set to /index.php, and you are correct by default IIS will drop all the form data when pages are processed this way.

If ISAPI was working it would interact and process the page first before it gets to this stage.

If you ever decide to try ISAPI rewrite again without any hacks just let me know.

Thanks Aaron

Man I never thought about that. People would have been using ISAPI_Rewrite when it was installed on their server and they didn’t have root access or a control panel with options to control custom error pages. With 404/405 set to /index.php MODx is handling the FURLs itself without ISAPI_Rewrite needing to do anything. That’ll save me $95 as I’m still working with the 45 day trial.

Any comments on my fix for IIS dropping the form data?

The $95 would be well spent, running stuff like friendly urls via custom error 404 is a very bad way to do it.

Not only will it drop your pages form data, it also tells google a 404 occurred in the background.

Not only will it drop your pages form data, it also tells google a 404 occurred in the background.

Are you sure about the 404 header? I have MODx set just now with 404 & 405 to /index.php and the httpd.ini file deleted from the root of the web server.

All pages on the website return the status as 200 OK when I check with the NET tab on Firebug:
http://modx103.cubeit.co.uk/design.html

Windows servers are my bread and butter so to speak.

The other problem of running it the way you are doing it is

• All forms will not work in the future unless you hack them
• Your website will never return a 404 page even if the doc does not exist (which will affect your web stats and knowing about errors / missing pages / bad links)

http://modx103.cubeit.co.uk/design333333 is an example of a page which should return a server response 404.

I could list many more but the simple answer is with IIS6 this is a very very bad way to handle friendly URLs.

I hope I’m not coming across as arguing with you or anything and I do understand your authority on this issue. I’m just trying to get a complete picture of what’s going on.

So you’re saying that even though my browser sees a 200 OK header for http://modx103.cubeit.co.uk/design.html

Check the line right at the bottom of the image.

and a 404 Not Found header for: http://modx103.cubeit.co.uk/design333333

404 right at the bottom in red.

That the likes of Google are actually seeing a 404 Not Found from IIS?

In that case am I correct to think I need to turn off the custom 404 and 405 error handling in IIS and reinstate httpd.ini with the following code for ISAPI_Rewrite 3:



Appreciate your time on this.

Chris