[#3739] - [Fix][#33829] Use 404 response codes when server URL rewriting is enabled
- Closed
- 9 Jun 2014
- Medium
- Build: staging
- # 3739
- Diff
- zjw:sef_url_rewrite_not_found_fix
- Foreign ID 33829
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Joomla Code Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33829&start=0
How to test:
Install Joomla 3.3.0 with some sample data on an apache server.
In the Site Settings, enable:
1. Search Engine Friendly URLs
2. Use URL rewriting
3. Adds Suffix to URL
Rename htaccess.txt to .htaccess to enable URL rewriting on the server.
Enter a URL for a non-existent file (assume the Joomla installation is at http://example.com):
http://examle.com/images/missing-file.pdf
The expected response is a "404" (not found) error.
The actual response is a "500" (internal server error) response. This response is misleading. There has been no "server error" -- it's simply a case of the client requesting a file that was not found on the server.
The issue is further exacerbated with the recent merging of pull request #488, because now any missing file with any file extension will be redirected to Joomla. If the file ends with anything other than ".html", the response will likely be 500 rather than 404.
This problem also affects the Redirect component. Although redirects can be created for missing files, the redirects will not be honored. An example redirect:
http://examle.com/images/missing-file.pdf -> http://example.com/index.php
Such a redirect will fail because it would only be honored when a 404 error
condition is encountered.
This issue is probably the same as issue #30344, but that was closed due to inactivity.
I didn't mention it here, but in the JoomlaCode Tracker item I did mention that the approach taken here was to avoid directly modifying JControllerLegacy::getView() in order to avoid any possibility of backward compatibility issues.
I fully agree with you that modifying the code in getView() would be a cleaner solution. If that approach is acceptable, then I would propose closing this request and creating a new request based on this diff.
I would prefer that
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-06-09 02:24:10 |
phproberto
-
I don't think it's wise to remap any 500 to 404. Wouldn't it be better to fix it downstream where the 500 error is thrown? Sounds to me like it should be a 404 there to begin with.