projects
asked on
apache prevent error for single directory/file
How can I prevent an error from being logged when clients cannot find a certain file in one sub-directory?
For example, say the file they cannot find at the time they looked was something.org and I don't want those misses to end up being logged.
For example, say the file they cannot find at the time they looked was something.org and I don't want those misses to end up being logged.
Dave Baldwin
But that is exactly why the logs are there. How many of those show that someone is trying to break in to you site? They will be shown in the access log on Apache.
ASKER
These are all authenticated connections so eliminating this particular error is not about hiding the errors or security, it's about getting rid of one obvious one without having to add code to our application. We want to know about any errors but this one is an obvious one and it's filling the logs for no good reason.
Anyhow, it's also an interesting question because this kind of thing has come up before and I'd like to know how to do it.
Anyhow, it's also an interesting question because this kind of thing has come up before and I'd like to know how to do it.
I don't see anything in the Apache docs that will let you select the kinds of errors that are recorded. Why are they asking for missing files in the first place?
To expand on Dave Baldwin's direction, the errors are there to show you something is going wrong. That something wrong may or may not be important - that is not for Apache to decide. It merely reports the parameters, status, and response for every request that comes in.
More importantly, treating the symptom (i.e., the 404) is not a good practice. Masking the generation of the 404 would simply prevent you from knowing something is wrong. Think ahead to 2 or 3 years from now, when the next developer/admin comes in and is tasked with debugging the application - s/he'll be lost trying to find the lost error message that SHOULD be reported.
Some options for you:
More importantly, treating the symptom (i.e., the 404) is not a good practice. Masking the generation of the 404 would simply prevent you from knowing something is wrong. Think ahead to 2 or 3 years from now, when the next developer/admin comes in and is tasked with debugging the application - s/he'll be lost trying to find the lost error message that SHOULD be reported.
Some options for you:
RECOMMENDED Handle the 404 in your code. If this is an expected error, then your code should be expecting it and be able to handle it accordingly, including a graceful failure, if required.
Use a custom solution, such as SetEnvIfPlus to send all your "expected" 404s to a separate log file
ASKER
As I said before, I fully understand why error logs are there and how useful they are. In this case, the script is looking for a file and when it is not there, an error is being generated. There is no actual error, only that the file is not there so this is generating a lot of errors in logs which I need to keep in order to find actual errors.
I don't need to know about the file missing error for this particular directory, only authenticated connections can look there anyhow.
I'm pretty sure this can be done or at least am pretty sure I've read that it can be done and isn't all that hard. Figured I would ask here but if there is no way of doing it, then I guess the code for the app will have to be modified.
I don't need to know about the file missing error for this particular directory, only authenticated connections can look there anyhow.
I'm pretty sure this can be done or at least am pretty sure I've read that it can be done and isn't all that hard. Figured I would ask here but if there is no way of doing it, then I guess the code for the app will have to be modified.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Semantics :).
Yes, there IS an error in the logs but this is not an actual error and I know that apache is doing it's job.
However, apache also has a lot of useful directives and ways of doing certain things at times and that is what I am looking for.
Instead of doing yet another read to the database, we simply look in a directory for a file. They aren't actually doing it that frequently but because there are a lot of clients, these are adding up to a log of errors being placed into the error log.
The file is an update that only authenticated clients can get to (a certain directory) which is why I really don't need to log errors for that particular directory.
Either way, as you said, we'll have to add some code into the app which would prevent this error.
Yes, there IS an error in the logs but this is not an actual error and I know that apache is doing it's job.
However, apache also has a lot of useful directives and ways of doing certain things at times and that is what I am looking for.
Instead of doing yet another read to the database, we simply look in a directory for a file. They aren't actually doing it that frequently but because there are a lot of clients, these are adding up to a log of errors being placed into the error log.
The file is an update that only authenticated clients can get to (a certain directory) which is why I really don't need to log errors for that particular directory.
Either way, as you said, we'll have to add some code into the app which would prevent this error.
ASKER
I'm not sure how to award this because for the most part, you kept telling me what I already know.
-I KNOW that this is apache doing what it is supposed to be doing.
-I KNOW that errors logs are important and that turning them off isn't a good idea (which is not something I even thought about doing)
-I KNOW that the application will need to be modified to eliminate the error but I was trying to avoid that.
I know all these things but my question was asking IF there is a way of eliminating errors for one particular directory.
>I heartily recommend trapping and resolving the missing file issue from inside your application
>If you're steadfastly determined to ignore that advice and the error being generated, using a custom
>solution like SetEnvIfPlus
It isn't a security issue, I know why it is happening and am not ignoring anything. This is a special case in my application where eliminating errors specific to one directory only would be easier than doing anything else.
The SetEnvIfPlus is actually one solution indeed and I've used it before but forgot about it. Thanks.
-I KNOW that this is apache doing what it is supposed to be doing.
-I KNOW that errors logs are important and that turning them off isn't a good idea (which is not something I even thought about doing)
-I KNOW that the application will need to be modified to eliminate the error but I was trying to avoid that.
I know all these things but my question was asking IF there is a way of eliminating errors for one particular directory.
>I heartily recommend trapping and resolving the missing file issue from inside your application
>If you're steadfastly determined to ignore that advice and the error being generated, using a custom
>solution like SetEnvIfPlus
It isn't a security issue, I know why it is happening and am not ignoring anything. This is a special case in my application where eliminating errors specific to one directory only would be easier than doing anything else.
The SetEnvIfPlus is actually one solution indeed and I've used it before but forgot about it. Thanks.
ASKER
Experts must not be hell bent on repeating the same things when the question specifically states that the poster is aware of certain conditions and understands the ramifications. Sometimes, there is a need to do something which may not sound right but it might be the right solution in certain cases.
The SetEnvIfPlus is actually one option and could have been mentioned early on.
Thanks.
The SetEnvIfPlus is actually one option and could have been mentioned early on.
Thanks.
Most server side languages let you check to see if a file exists. This is done outside of Apache so it doesn't show in the error logs. PHP example: http://php.net/manual/en/function.file-exists.php This function will show a 404 if you check for a URL instead of a file.
>>> It isn't a security issue, I know why it is happening and am not ignoring anything.
But you are ignoring it. In fact, you came here for help with ignoring it. It doesn't matter if it is a security issue or not. The point behind our advice is that you are not dealing with a known error condition. The fact that it is expected means you could very well anticipate it and handle it gracefully, as you should.
>>> Sometimes, there is a need to do something which may not
>>> sound right but it might be the right solution in certain cases.
From everything you've described and explained, ignoring the error is not the right solution. Ignoring an error, expected or not, is rarely the right way to go. I find it to be a lazy or sloppy strategy, and usually ends up causing some sort of complication down the line. It's always best to do it right the first time.
>>> Experts must not be hell bent on repeating the same things when the question
>>> specifically states that the poster is aware of certain conditions and understands
>>> the ramifications.
It may not be something you want to hear, but I always endeavor to give a petitioner the *right* answer, not the comfortable one. I don't like repeating myself either... when I do, it is usually because the person coming to me for help/advice ignored it the first time, and it bears repeating.
>>> The SetEnvIfPlus is actually one option and could have been mentioned early on
I did - in my first post, and again in my second. See above.
>>> Most server side languages let you check to see if a file exists.
That is the correct answer. If you're using a client-side request to check for the file, then creating an API wrapper to gracefully avoid the error would be a suitable approach.
Good luck!
But you are ignoring it. In fact, you came here for help with ignoring it. It doesn't matter if it is a security issue or not. The point behind our advice is that you are not dealing with a known error condition. The fact that it is expected means you could very well anticipate it and handle it gracefully, as you should.
>>> Sometimes, there is a need to do something which may not
>>> sound right but it might be the right solution in certain cases.
From everything you've described and explained, ignoring the error is not the right solution. Ignoring an error, expected or not, is rarely the right way to go. I find it to be a lazy or sloppy strategy, and usually ends up causing some sort of complication down the line. It's always best to do it right the first time.
>>> Experts must not be hell bent on repeating the same things when the question
>>> specifically states that the poster is aware of certain conditions and understands
>>> the ramifications.
It may not be something you want to hear, but I always endeavor to give a petitioner the *right* answer, not the comfortable one. I don't like repeating myself either... when I do, it is usually because the person coming to me for help/advice ignored it the first time, and it bears repeating.
>>> The SetEnvIfPlus is actually one option and could have been mentioned early on
I did - in my first post, and again in my second. See above.
>>> Most server side languages let you check to see if a file exists.
That is the correct answer. If you're using a client-side request to check for the file, then creating an API wrapper to gracefully avoid the error would be a suitable approach.
Good luck!
ASKER
I like the 'right' answer and appreciate them which is why I am on this site. However, no one has given the the RIGHT answer. I simply wanted to know if there is a way of disabling errors for one particular directory.
I have my own reasons, even tried to explain them a little but my question still remains, I am looking to know how to prevent errors from one directory only without having to mess with the code.
Thanks.
I have my own reasons, even tried to explain them a little but my question still remains, I am looking to know how to prevent errors from one directory only without having to mess with the code.
Thanks.
Both Dave and I presented the right answer. Your refusal to accept it does not alter its correctness.
To sum up:
- Vanilla Apache does not provide the feature you are requesting
- Apache is not the proper level of the stack to deal with this issue - your code is the proper place
- The custom SetEnvIfPlus module can be used to simulate this
To sum up:
- Vanilla Apache does not provide the feature you are requesting
- Apache is not the proper level of the stack to deal with this issue - your code is the proper place
- The custom SetEnvIfPlus module can be used to simulate this
And I agree with Steve. All methods of making that error disappear involve "having to mess with the code" in some way. I think it is better to make changes in your code than trying to rewrite that section of Apache.
ASKER
First of all, I always strive to be fair and since I've you seen on many of my questions, you already know this.
Second, I picked the answer which was in fact a solution as opposed to being told why I should not do this even though I said many times that I had my own reasons for it.
Your answers are correct in most situations but not in this one. In this one, I specifically wanted to know if it is possible to prevent an error from being logged in one directory only.
Why flog a dead horse?
Second, I picked the answer which was in fact a solution as opposed to being told why I should not do this even though I said many times that I had my own reasons for it.
Your answers are correct in most situations but not in this one. In this one, I specifically wanted to know if it is possible to prevent an error from being logged in one directory only.
Why flog a dead horse?
ASKER
http://httpd.apache.org/docs/2.2/logs.html
Conditional Logs
There are times when it is convenient to exclude certain entries from the access logs based on characteristics of the client request. This is easily accomplished with the help of environment variables. First, an environment variable must be set to indicate that the request meets certain conditions. This is usually accomplished with SetEnvIf. Then the env= clause of the CustomLog directive is used to include or exclude requests where the environment variable is set. Some examples:
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog
As another example, consider logging requests from english-speakers to one log file, and non-english speakers to a different log file.
SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english
Although we have just shown that conditional logging is very powerful and flexible, it is not the only way to control the contents of the logs. Log files are more useful when they contain a complete record of server activity. It is often easier to simply post-process the log files to remove requests that you do not want to consider.
Conditional Logs
There are times when it is convenient to exclude certain entries from the access logs based on characteristics of the client request. This is easily accomplished with the help of environment variables. First, an environment variable must be set to indicate that the request meets certain conditions. This is usually accomplished with SetEnvIf. Then the env= clause of the CustomLog directive is used to include or exclude requests where the environment variable is set. Some examples:
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog
As another example, consider logging requests from english-speakers to one log file, and non-english speakers to a different log file.
SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english
Although we have just shown that conditional logging is very powerful and flexible, it is not the only way to control the contents of the logs. Log files are more useful when they contain a complete record of server activity. It is often easier to simply post-process the log files to remove requests that you do not want to consider.