StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You have 2 errors:</p> <ol> <li>You don't have permission to access /admin/product/add/ on this server.</li> <li>Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.</li> </ol> <p>The 2nd one is quite certainly a consequence of the same bug. You may have something in your apache configuration which remove 404 errors from default http server handling and push it to your php application, if this php application was working we would have a nice 404, but...</p> <p>The first one tells you your php application is not running at all.</p> <p>So. This first error tell us that apache did try to directly access the directory <code>/path/to/documentroot/admin/product/add/</code> on your server and to produce a listing of it (well a listing of the directory content would be done only if apache were authorized to do so). But of course this is not a real directory on your server. It is a <strong>virtual path</strong> in your application. So apache ends up with a 404 (which leads to error 2).</p> <p>The application handles a <strong>virtual</strong> path, apache does not manage it. The RewriteRule job is to catch the requested path <strong>before</strong> apache is trying to serve it and give it to one single php file (<code>index.php</code>) as a query string argument.</p> <p>So... this rewrite rule was not applied. Things that could prevent this rule to be applied are numerous:</p> <ol> <li>mod_rewrite not activated: is the module present and enabled (<code>RewriteEngine on</code>)?</li> <li>syntax error: mod rewrite syntax is quite hard to read, sometimes really complex. But here it seems quite simple.</li> <li>The RewriteRule resulting file is maybe not a valid target for apache. If the index.php file is not present in the DocumentRoot, or not readable by the apache user, then apache will fail. <strong>Warning</strong>: having a file readable by the apache user means having read rights on the file but also <strong>execution</strong> rights on all <strong>parents directories</strong> for the apache user. This is where your classical <code>chmod</code>/<code>chown</code> solutions are fixing the problems.</li> <li>The rule must be in a valid configuration file. Is this rule in a an apache configuration file, inside a Location or Directory section? Or maybe in the global scope -- this may alter the rewrite Rule syntax--. Or is it in a .htaccess file? If it's a .htacces does apache reads the .htacces files and are mod-rewrite instructions allowed there (<code>AllowOverride None</code>). Isn't there others .htaccess files taking precedence?</li> </ol> <p>So to fix the problem:</p> <ul> <li>If you have an apache version greater than 2.2.16 you can replace the RewriteRule by <strong><a href="http://httpd.apache.org/docs/2.4/mod/mod_dir.html#fallbackresource" rel="nofollow noreferrer">FallbackRessource /index.php</a></strong> to check that this does not come from a mod-rewrite problem.</li> <li>try to <strong>directly</strong> request <code>index.php</code>, so that at least a direct request to this file does work</li> <li>try to <strong>directly access a valid ressource</strong> on the documentRoot (a txt file, an image, something that should not be handled by the rewrite but directly served)</li> <li>check that if any of your virtual paths could map real physical paths Apache is not trying to serve the physical one (like when you write a <code>RewriteCond %{REQUEST_FILENAME}-d</code>) but really push the path to <code>index.php</code></li> <li>check apache error <strong>logs</strong>.</li> <li><strong>debug</strong> mod_rewrite with <code>RewriteLog</code> and <code>RewriteLogLevel</code></li> <li>collect facts, settings and tests, and then push that to SO or <a href="http://serverfault.com">Servfault</a>.</li> </ul> <p>So the problem is quite simple: the php application is not receiving the request. But there are a very big number of ways to end in this state. The message in itself is not very important. The only way to find the error is to check all parameters (or to have years of bug fixing experience and developing a pre-cognitive intuition organ for lamp bugs -- usually a beard --, like admins). And the only way for us to help you is to find strange facts in a big list of configuration details, this is why good questions contains a lot of informations, even if all theses informations looks simply "classical" for you.</p> <p><strong>EDIT</strong></p> <p>To clarify the problem you should edit your answer, track the <code>POST</code> requests with tools such as Chrome developpers tools or firebug (keep the network tracking in record mode to catch several POSTS) or try to replay the post with Live HTTP headers reply. You should try to isolate the problematic POST and give us details. Debug is not magical.</p> <p>Now I know one magical random POST failure. It's the empty <strong>GET url bug</strong>. It could be that (or not). If you have one empty GET url hidden somewhere (<code><IMG SRC=""></code>, <code>url()</code> in css, or an empty LINK in headers for example. As theses hidden POST are defined in HTTP as "replay-the-request-which-launched-the-source-page, and some browsers even replay the POST that gives you the page if they found one. This could lead to broken hidden POSTS.</p> <p>It could be also that the POST is not sent to the right server. Hard to say. So please collect informations from your comments, add some more network analysis and edit the question which is now really containing not enough facts.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload