previous questoin... maybe I'm grabbing at straws...

Ilan Berkner iberkner at gmail.com
Thu Jan 15 23:46:01 MSK 2009


Thank you for your response.

1. Inspecting the headers with Firebug is not an option as I don't have
access to the system causing the problem (its not a virus / or bot, I'm
pretty sure its one of our apps that is causing it).
2. $http_referer is already part of the access log format and is coming up
blank.

I am thinking of writing some custom code to catch this particular issue and
see if I can get more info on it.

Thanks

On Thu, Jan 15, 2009 at 3:35 PM, Juan Fco. Giordana
<juangiordana at gmail.com>wrote:

> You could inspect the headers with firebug or similar tool or add the
> $http_referer variable to the log format to see what is causing that or even
> a rewrite rule to catch the request in a php script and logs its output in
> another file or in a DB.
>
> Ilan Berkner wrote:
>
>> I previously posted a question about getting more information about an
>> error that we're getting in our Nginx log files.  The error is as follows:
>>  2009/01/15 11:47:57 [error] 15704#0: *689561 open()
>> "/home/spellcit/public_html/letters/.mp3" failed (2: No such file or
>> directory), client: 204.38.160.220, server: www.spellingcity.com <
>> http://www.spellingcity.com/>, request: "GET /letters/.mp3 HTTP/1.1",
>> host: "www.spellingcity.com <http://www.spellingcity.com/>"
>> What I'm trying to figure out is which php or swf script (or maybe its not
>> a php or swf script) is actually making the call to request this
>> non-existent file.
>>  Out of 25,385 errors in our log, 16,952 are caused by this issue.
>>  One of the suggestions I got was to turn on the access logs, which I did.
>>  In looking at this IP address at the access logs, this is what I get, which
>> unfortunately is not much.
>>
>> 204.38.160.220 - - [15/Jan/2009:12:31:26 -0600] 404 "GET /letters/.mp3
>> HTTP/1.1" 169 "-" "Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.0.2)
>> Gecko/20030208 Netscape/7.02" "-"
>>  I was thinking about creating a dummy ".mp3" file (or rewrite rule) to
>> capture traffic and get try to get some more info out of the header... just
>> a thought.
>>  Any suggestions / thoughts would be very much appreciated.
>>  Ilan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090115/ad7f2d30/attachment.html>


More information about the nginx mailing list