The purpose of HTTP/1.1 status codes is stated in RFC 2616. It indicates that 4xx status codes represent a Client Error (The request contains bad syntax or cannot be fulfilled). In that sense, a 404 error and a 405 error are both errors. Since they are both errors, it seems sensible to me to have both types of errors appear in a single error report.
You indicated that user misbehavior might be the cause of your 405 errors. Let's consider another scenario that also involves user misbehavior. I maintain a site for a public university. The main page and many subpages have a link to Index A-Z. In spite of the links, I get lots of 404 errors like "www.domain.tld/math" and "www.domain.tld/scholarships". People are guessing at the location of the Math Department. People are guessing at the address of the Scholarship Office. I don't have any URIs even remotely like those, so it can't be my fault that I have 404 errors appearing in the Failure Report. It's user misbehavior that produces my 404 errors, just as user misbehavior seems to produce your 405 errors. But, the RFC makes no exclusion for user misbehavior. So, despite the cause, an error is an error unless/until the RFC is modified, or superseded by another RFC (HTTP/1.2?).
Personally, having all errors in a single report helps me (and my boss) to quickly determine whether any corrective action is needed to improve server performance. Granted, we do get tired of seeing some data repeated every week, but that is the fault of users, not Analog.
Hope that helps,
-- Duke
Rick Mallett wrote:
On Fri, 18 Mar 2005, Stephen Turner wrote:
On Fri, 18 Mar 2005, Rick Mallett wrote:
I've temporarily fixed this problem using "STATUSEXCLUDE 405", but I tend to think that its a bug to include failed PROPFINDs in the FAILURE report. I don't run WebDAV, BTW, and all of these requests appear to be probes from an unknown source.
I don't understand why you think it's a bug. It seems to me that there was a failed request on your server and analog reported it correctly.
I suppose that's true, but it seems to me that the purpose of the
FAILURE report is to show references to files that don't exist, either
because they have been moved, or because the name was misspelled in
the reference document, since this allows the site maintainer to find
and correct bad links and to identify pages that should be given a a custom 404 page treatment.
A status code of 405 on a PROPFIND means "Method Not Allowed" and I don't think this should be treated the same as a 404 on a GET, POST, or PUT request, especially since sites that don't even implement WebDAV aren't likely to have any interest in failed PROPFINDs. In this case the PROPFINDs are more like web spam, than valid requests, and I guess it should be reported somewhere so that I will know about it, but it bloats the FAILURE report IMO and its misleading to see a failed request against a file that you know does exist and is GETable.
OTOH the fact that I can choose to ignore these requests using "STATUSEXCLUDE 405" would seem to support the argument that its not a bug, its a feature, but I think that might be worth reviewing, and at the very least commenting on in the documentation.
However, I'm wondering why I have to match the entire path when its a regexp, since ^ and $ are
available for indicating the beginning and end of the string and its
fairly common practice (in Perl at least) to use these to anchor the
pattern to a indicate a specific substring to match and replace.
If there is a good reason why allowing substring replacement isn't feasible, making this clear in the documentation would be a help.
It matches the syntax in the (older) non-regexp case better.
Fair enough, but it would help if this were made clear in the documentation. Just a suggestion mind you. I really appreciate all of the work that you have done on analog and wouldn't want any of my comments/suggestions to be taken as being critical of those efforts. I've been using analog for several years and I think its a great program.
- rick +------------------------------------------------------------------------ | TO UNSUBSCRIBE from this list: | http://lists.meer.net/mailman/listinfo/analog-help | | Usenet version: news://news.gmane.org/gmane.comp.web.analog.general | List archives: http://www.analog.cx/docs/mailing.html#listarchives +------------------------------------------------------------------------
begin:vcard fn:Duke Hillard n:Hillard;Duke org:University of Louisiana at Lafayette;University Computing Support Services adr:;;P.O. Box 42770;Lafayette;LA;70504-2770;USA email;internet:[EMAIL PROTECTED] title:University Webmaster tel;work:337.482.5763 x-mozilla-html:TRUE url:http://www.louisiana.edu/ version:2.1 end:vcard
+------------------------------------------------------------------------ | TO UNSUBSCRIBE from this list: | http://lists.meer.net/mailman/listinfo/analog-help | | Usenet version: news://news.gmane.org/gmane.comp.web.analog.general | List archives: http://www.analog.cx/docs/mailing.html#listarchives +------------------------------------------------------------------------
