Apache / Zend Framework - Error Log - Page Not found - php

This one is a little confusing to me.
I'm running a LAMP server with Zend Framework. I've spent a lot of time going over my error logs to try and clean-up any programming errors/bugs.
Most of my specific site errors are done but I looked into my general Apache error log:
/var/log/apache2/error.log
And I'm seeing a lot, almost constant, errors for "File does not exist" like the following (simplified for brevity):
[date] [error] [client #:#:#:#] File does not exist: /var/www/sites/[website folder]/public/explore
[date] [error] [client #:#:#:#] File does not exist: /var/www/sites/[website folder]/public/where-to-buy
[date] [error] [client #:#:#:#] File does not exist: /var/www/sites/[website folder]/public/products
And so on. These folders do not exist because all requests are suppose to be redirected into the index.php file and handled by Zend Framework. The actual controllers and actions exist, such that anyone going to:
http://www.example.com/explore
or
http://www.example.com/where-to-buy/
will get the correct page via Zend Framework.
But I'm not understanding why all these errors are occuring?
If figure it might have something to do with the .htaccess file that redirects most requests (excluding style sheets, documents, images, etc) to the index.php script. This is what mine looks like:
RewriteEngine On
# make sure all requests go to 'www' sub-domain
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
# Zend Framework, redirect requests to index.php
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
Is Apache trying to resolve the request via an actual directory first and then passing the request to index.php? Which causes the error request?
I'm also not sure why this is getting dumped into the default error log, instead of the error log or the specific site. In other words, I have error logs for each domain such as "example.com_error.log". That might be another indication to the issue. It might be a sequence thing as "error.log" is tired to a "default" site.
Thanks for any insight!
Fozzy

From Regilero:
the fact this is going to the default log is effectively a good hint
on the problem, check the related access.log. Maybe some requests made
on a DNS name not handled in your virtualhost or by web clients not
using HTTP 1/1 (so with no host header) – regilero Oct 19 '11 at 22:52
I was able to compare the access.log with the error.log to investigate my issues.
It was awhile ago but I believe the issue was due to some script going directly to the server via an IP address and trying to use the directory structure from one of the virtually hosted domains.

Related

URL rewriting with parameters in .htaccess

I've been searching lot of related tutorials and so on from Google to solve this on my own, but with zero luck. Therefore I am here to ask. I am trying to 'prettify' my project URL by rewriting. I am not sure are these all achievable anyhow, because I am just starting to get my head around the subject.
I am working 'example' on localhost project folder localhost/example. File '.htaccess' is located in that folder. Where I have set the following:
RewriteEngine On
RewriteBase /example
So basically my application now generates a URL consisting at least 1 parameter all the time and another pointing current location.
Current URL: localhost/example/admin.php?e=2&p=frontpage
Fantasy: localhost/example/admin/2/frontpage
About the parameters:
p stands for selected page
e stands for event
Okay lets think this all is achievable easily, do I have to change all the attributes to match current shown url?
Now they are:
href="?e=2&p=settings"
Should they be:
href="2/settings" ?
I am checking what value GET parameter P has, then including that page into content area.
That is pretty much it, pretty too complex for me, but for education purposes I really want to understand this thru and thru. Thank you.
EDIT:
With the added
RewriteRule ^admin.php/(.*)$ /admin.php?e=$1 [L,QSA]
I am getting lot of pathing errors, whole site is without styling and js files.
EDIT 2:
RewriteEngine On
RewriteBase /example
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule /admin.php/e=?(.*)$/p=?(.*)$ /admin.php?e=$1?p=$2 [L,QSA]
Now urls are following:
http://localhost/example/admin.php/2/inc/vex/vex.css
http://localhost/example/admin.php/2/css/modestgrid.css
It is not showing the page in url and the paths are not correct.
They should be http://localhost/example/admin.php/css/modestgrid.css
Your question is a bit vague, contradictory and it is unclear how you actually want to handle (reference) your asset files. But in general I'd say this should be a starting point to get you going:
RewriteEngine On
RewriteBase /example
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)/([^/]+)/(.*)$ $1.php?e=$2&p=$3 [END]
For this to work you obviously need the apache rewriting module to be installed and loaded, you need to take care that the interpretation of dynamic configuration files is enabled at all (AllowOverride directive) and you have to place such file in the correct location with reading permission for the http server process.
In case you get an internal server error (http status 500) for that chances are that you operate a very old version of the apache http server. In that case you probably need to replace the [END] flag with the [L] flag which probably will work here too. You will find a hint on that in your http servers error log file in that case.
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only supported as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).

Internal Server Error 500 on a blank php file

Sorry if this seems obvious. I'm very new to this, but I've been stuck on this problem for hours even after searching around for similar problems.
I am using the cpanel for managing the files.
Initially, I tried uploading a simple php file, but I kept on getting problems, so I tried an empty php file. This is the error I constantly receive.
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.`
Please contact the server administrator at webmaster#mywebsite.com to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.`
After some more searching, I read about the .htaccess file.
I couldn't find the .htaccess, even after enabling "Show Hidden Files (dotfiles)" in the setting, so I created one. An empty one didn't work. I tried to look for what to place there and tried this.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*)$ file.php?url=$1 [QSA,L]
</IfModule>
In the error of the cpanel, this is what I receive
:error] [pid xxxx:tid xxxx] (12)Cannot allocate memory: [client xxxx] couldn't create child process: /usr/sbin/suphp for /home3/xxxx/public_html/file.php
I also tried to set the file permission to 644, and the folder to 755, but to no avail.
There were some other posts here about the php.ini and some commands in the command line, but I don't really know where to find them. There was also something about apache? but in the cpanel menu, there was only the apache handlers. Any help would be greatly appreciated! Again, sorry. I'm really new and I have no idea what I'm doing.
If it helps, the web hosting that I am using is zoom.ph (not sure if that is the proper term)
if you are using Mac localhost thats is normal because Mac doesn't show .htacces files you can enable hidden files open terminal and enter
defaults write com.apple.finder AppleShowAllFiles YES
after that enter ;
killall Finder /System/Library/CoreServices/Finder.app
this problem has many causes please be sure your project directory is correct ! and change your code with this;
RewriteEngine On
RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2$
RewriteEngine On Options All -Indexes RewriteBase /directoryname/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ file.php?url=$1 [QSA,L]
Perhaps you already hit the limit of your allowed resources of your hosting, i found this on zoom.ph:
Fair Use Policy
This is where we really shine! Most hosting providers in the Philippines are resellers who are reselling cheap, traditional VPS services of other hosting firms. Often times, these hosting providers oversell their packages to the extent of offering unbelievable packages with unlimited disk and bandwidth, which means that they are selling resources more than the actual resources allotted to them by their parent hosting provider. This oftentimes results to resource hogging causing "500 Internal Server Error". Looks familiar?
Our system is designed to protect tenants from noisy neighbors which means that if one account turns to be consuming resource more than what is allotted for that account, then only that account will run out of resource but the rest of the tenants will be operating normally.
Although we know that diverse customer base will have different hosting package use cases, we cannot allow one account from disrupting shared services. To prevent this, all use cases are governed by our Acceptable Usage Policy or AUP. This AUP protects users from other kind of abuse that cannot be prevented automatically in a shared server environment.
At ZOOM Hosting, you will get the computing resource that you are paying for. We'll allow you to install whatever account level scripts you want to install provided it does not fall under unacceptable materials in our AUP. That's what we advertised and that's what we are giving you. Our packages are carefully designed to serve the needs of almost all business scales, from micro business to a global enterprise. We host small sites such as dental clinics to medium traffic websites such as those of the NGOs and SMEs to high traffic sites such as government, international remittance firm and ecommerce sites getting global visitors daily

Copied WordPress site now "blank"?

I just copied a site over to a new developmental subdomain for some changes. The copy went fine. I used rsync and all files are in place. I dumped the db contents and loaded them up.
Additionally I modified the wp-config.php so that it would have:
define('WP_HOME','http://www.dev.newdomain.tld');
define('WP_SITEURL','http://www.dev.newdomain.tld');
// Just trying to catch any error info:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
#ini_set('display_errors',0);
define('SCRIPT_DEBUG', true);
Posts, plugins, users, etc. all show up just fine on the wp admin interface, however NO content is being displayed on the front end.
If I modify an article from the wp admin, it edits just fine, however when I attempt to view a post I get the following in my browser:
Not Found
The requested URL /path-to-article/ was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
And the following in my apache error.log:
[Tue Feb 05 05:50:07 2013] [error] [client xxx.xxx.xxx.xxx] File does not exist: /home/username/dev.domain.tld/path-to-post
[Tue Feb 05 05:50:07 2013] [error] [client xxx.xxx.xxx.xxx] File does not exist: /home/username/dev.domain.tld/missing.html
This part leads me to believe that perhaps it is something going on with apache's .htaccess, however it seems to look okay:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
And yes, I have disabled all plugins to see if there could be something going on there. Further, changing the theme to the default "Twenty Twelve" also does not help.
Additionally when looking at the generated page source, there is simply no content within the html.
All I see is a singular access in the access log for the web browser to the root / site resource with NO accompanying other resources (files, images, etc.)
What could be going on here as I am seemingly at an impasse with no errors within the logs whatsoever?
Check your database. Wordpress stores many URLs as absolute URLs, so that's why you might have problems.

POST request to SEO URL Forbidden

I have a basic MVC system that is sending POST data to URLs such as
admin/product/add/
But this is giving me an error
Forbidden
You don't have permission to access
/admin/product/add/ on this server.
Additionally, a 404 Not Found error was encountered while trying to
use an ErrorDocument to handle the request.
The RewriteRule is simply
RewriteRule ^(.*)/$ index.php?uri=$1
Last time I saw this on a server changing file/directory permissions to 755 seemed to fix it but not this time. I have never really understood the reason for the error so was hoping someone may be able to provide some more information?
You have 2 errors:
You don't have permission to access /admin/product/add/ on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
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...
The first one tells you your php application is not running at all.
So. This first error tell us that apache did try to directly access the directory /path/to/documentroot/admin/product/add/ 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 virtual path in your application. So apache ends up with a 404 (which leads to error 2).
The application handles a virtual path, apache does not manage it. The RewriteRule job is to catch the requested path before apache is trying to serve it and give it to one single php file (index.php) as a query string argument.
So... this rewrite rule was not applied. Things that could prevent this rule to be applied are numerous:
mod_rewrite not activated: is the module present and enabled (RewriteEngine on)?
syntax error: mod rewrite syntax is quite hard to read, sometimes really complex. But here it seems quite simple.
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. Warning: having a file readable by the apache user means having read rights on the file but also execution rights on all parents directories for the apache user. This is where your classical chmod/chown solutions are fixing the problems.
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 (AllowOverride None). Isn't there others .htaccess files taking precedence?
So to fix the problem:
If you have an apache version greater than 2.2.16 you can replace the RewriteRule by FallbackRessource /index.php to check that this does not come from a mod-rewrite problem.
try to directly request index.php, so that at least a direct request to this file does work
try to directly access a valid ressource on the documentRoot (a txt file, an image, something that should not be handled by the rewrite but directly served)
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 RewriteCond %{REQUEST_FILENAME}-d) but really push the path to index.php
check apache error logs.
debug mod_rewrite with RewriteLog and RewriteLogLevel
collect facts, settings and tests, and then push that to SO or Servfault.
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.
EDIT
To clarify the problem you should edit your answer, track the POST 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.
Now I know one magical random POST failure. It's the empty GET url bug. It could be that (or not). If you have one empty GET url hidden somewhere (<IMG SRC="">, url() 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.
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.
Try this:
RewriteCond %{REQUEST_METHOD} =POST
RewriteRule ^(.*)/$ index.php?uri=$1
Use this:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?uri=$1 [L]
Also use only www or non-www domain but not both at the same time. Redirect users with htaccess where you would like like to...
NonWWW to WWW:
RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
WWW to NonWWW:
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^www\.(.*)$ http://%1/$1 [R=301,L]

Adding mod-rewrite to an existing PHP website

I am updating a php app, which currently does not use url rewriting. The aim is to hide file extensions. The general structure of the website is as follows
root/
index.php
login.php
page1.php
page2.php
page3.php
page4.php
page5.php
page6.php
page7.php
page8.php
subfolder/
index.php
validpage.php
images/
css/
The subfolder folder in the above structure is unique in that it is the only subfolder containing php files.All of the other files are in the root folder.
I have been through these questions Mod Rewrite and PHP and Mod-Rewrite or PHP router? and mod_rewrite, php and the .htaccess file
Updated htaccess. thanks to #thomasmalt
RewriteEngine on
RewriteBase /
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -l
RewriteRule ^.*$ - [NC,L]
# only rewrite if the requested file doesn't exist
RewriteCond %{REQUEST_FILENAME} !-s
# add .php to the url
RewriteRule ^(.*)$ $1.php
Problem now is I get a 500 instead of a 404 error, when I try to access a non existent page like localhost/inex.php. The Apache error log gives me the following errors. (I accessed localhost/index which loaded the contents of index.php , followed by which I loaded localhost/inex which gave me a 500 error.)
[Sat Sep 25 14:44:26 2010] [error] [client 127.0.0.1] File does not exist: C:/wamp/www/index
[Sat Sep 25 14:44:36 2010] [error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Update: found the answer to my question here. The question is resolved.
Apache has an option: Options +MultiViews
If you enable this, you don't need to place the file-extention in the url.
I'm not totally sure what you're trying to achieve, and i suspect, no disrespect intended, that you need to understand both mod_rewrite, and the way the webserver and php parses and executes files. I'm not sure how to answer without shooting over or under your level of understanding, but I'll try.
I can tell you what you're current .htaccess is doing: (pseudocode)
if REQUEST_FILENAME does not exist then
rewrite request to /index.php/<the request>
Since index.php is your php script that is executed and everything put in $1 is ignored.
That's why index.php is executed whatever you do.
What you could try to put in your .htaccess is this:
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^(.*)$ $1.php
That should take the request and try to append .php to the end of it. I haven't tested it unfortunately, but you should give it a try. The result should be something like this:
if request is "/news/article"
translate it to "/news/article.php"
And you should read the mod_rewrite documentation twice a day for a month, and buy the O'Reilly book about Regular Expressions.
And if you have administrator access to the development server you should look into
RewriteLogLevel
RewriteLog
From experience, it's harder than it sounds to retro-fit mod_rewrite into an existing site.
This isn't because mod_rewrite is hard -- actually it's relatively easy to set it up and get your new URLs working. The reason it's hard is because your existing site will have all the old URLs hard-coded into it, so you'll have to go through your code changing them all to point to the new URL format - this can be especially tricky if your code builds up URL strings dynamically. You'll need to do lots of testing to make sure you've picked up every possible variation and that they all still work.
Also worth mentioning that search engines and external sites will have historic links in to your site using the old URLs, so you can't get rid of them completely.
I know that doesn't answer your question, but I believe these are important things to consider before you start the project, because for an existing site it isn't the quick-fix that some people make it out to be.
It send you to root because you have RewriteBase / what defining default base ...
If you want to stay in subfolder just make another .htaccess in subfolder with RewriteBase /subfolder/
or remove it
you can make condition like you want
RewriteRule ^(([0-9]+)-)?page(-([0-9]+))?/?$ index.php?page=$2&id=$4 [L]
this will take you from www.abcd.com/2-page-3 to www.abcd.com/index.php?page=2&id=3
Code in index.php doesn't need to contain anything.

Categories