View Full Version : Puzzling entry in logs
Arthur
11-01-2001, 08:07 AM
How did the following get in my log file?
(snip) "GET http://www.ebay.com/ HTTP/1.1" 200 6131 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"
(snip) "GET http://www.yahoo.com/ HTTP/1.1" 200 6131 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)"
(snip) "GET http://www.s3.com/ HTTP/1.1" 200 6128 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"
These are all from different IPs on different days. I tried; http://mydomain/http://www.yahoo.com, but that shows a 404 error and the request is logged as "GET /http://www.yahoo.com ...". So how did these entries get there?
Justin
11-01-2001, 05:15 PM
It looks like IE4 decided to act odd... I've seen that happen a number of times (with both IE and Netscape). Sometimes when clicking a link the browers seems to get confused, and instead of conneting to the new site, it tries to GET the URL from your server...
It's safe to ignore it anyway; I'm not quite sure why they got a 200 response code (HTTP OK), seems a 400 Bad Request or at least a 404 would have been appropriate... but in any case, it's a browser quirk.
That does seem odd...
Sometimes when clicking a link the browers seems to get confused, and instead of conneting to the new site, it tries to GET the URL from your server...
That seems counter-intuitive, though. Would the Apache server log what the browser thought the browser was doing, or what the Apache server actually retrieved? Especially in light of the 200 OK status, which should mean that the Apache server sucessfully retrieved and sent the page.
<edit>
Perhaps it is Apache that is getting confused, rather than the browser?
</edit>
Rich
-- confused, too
Terra
11-01-2001, 08:25 PM
(snip) "GET http://www.ebay.com/ HTTP/1.1" 200 6131 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"
(snip) "GET http://www.yahoo.com/ HTTP/1.1" 200 6131 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)"
(snip) "GET http://www.s3.com/ HTTP/1.1" 200 6128 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"
Look at the URL carefully...
This tells me someone was most likely playing with mod_rewrite and tried to do a redirect without adding the [R] statement...
RewriteRule ^/blah.html$ http://www.s3.com/
Would in fact rewrite:
/blah.html --> http://www.s3.com/
and log it as such...
This is why mod_rewrite can be so dangerous, since it allows Apache to do things beyond the norm...
The only other instance I can think of is:
http://www.yourdomain.com/http://www.s3.com/
but this is logged as a 404: "GET /http://www.s3.com/ HTTP/1.0"
So the only thing that can cause the above is 'mod_rewrite'
Your Honor, I rest my case... :P
--
Terra
--Who do you want to confuse today?--
FutureQuest
That makes sense. It all too easy to confuse the referer with the target.
Rich
-- mod_rewrite: caution, usage might require a secret decoder ring
Arthur
11-02-2001, 05:21 AM
Objection, your Honour! That's speculation.
Yes, I admit I am a user of mod_rewrite, but I have never tried to redirect to any of the before mentioned websites. I had the opportunity, but I have no motive.
The only thing I use mod_rewrite for is keep those pesky probes from Nimda and the like out of my error log by sending them an empty 410 message.
If these entries do indeed come from usage of mod_rewrite as you allege, I'm sure it wasn't caused by any of my actions. Maybe it was something at server level?
The entries in this case were made on October 7, 8, 12 and 13, 4 in total, 3 different IP addresses, but always the same browser (IE 4.01).
Arthur
-- I have an alibi
Terra
11-02-2001, 05:36 AM
LOL!!!
Then it must be the Microsoft!
They have never have an alibi...
However, have they ever assumed an inkling of guilt - ever...
Hmmm, maybe not...
Microsoft can pay a million people to rip your alibi to shreds...
Then it must simply be the customer that is using IE...
All Your IE Error Are Belong To You!
--
Terra
--Was it the Chad???--
FutureQuest
Arthur
11-02-2001, 06:07 AM
This if fun! I just tried telnetting to the webserver and then requesting GET http://www.yahoo.com . And it does get logged as such (with code 200), but the page displayed is my index page.
The entries are the only entries by those IP addresses, i.e. there's only one request from those addresses, no pages or images were requested. IE must have been really confused :crazy:
sheila
11-02-2001, 06:59 PM
Yes, I've seen this in my logs before, too. I don't recall which domain was requested, but it was certainly one that I don't host! And just like in Arthur's case: served up the page with a 200 code in the logs.
And I've never even dared to THINK about using mod_rewrite (yet).
If you can reproduce the log entry using telnet, that pretty much eliminates the browser as the source of the problem...
Rich
Arthur
11-03-2001, 09:45 AM
If you can reproduce the log entry using telnet, that pretty much eliminates the browser as the source of the problem... Why? Three persons telnetting to my site and then requesting another site, which results in seeing the index page from my site, would be really weird. And the browser identification is also exactly the same and Sheila reports it happened on her site too.
I think it's a pretty safe bet that it is the browser.
If you can reproduce the log entry using telnet, that pretty much eliminates the browser as the source of the problem...
Actually, not being able to reproduce the log entry using the browser would pretty much eliminate the browser as the source of the problem. Reproducing it through telnet would merely add a second plausible cause. ;)
Dan
I guess there is something here I don't understand...
Why? Three persons telnetting to my site and then requesting another site, which results in seeing the index page from my site, would be really weird.
No one should be able to telnet to the server (you can't technically telnet to a 'site') except you unless you give them your username/password.
I don't think I understand how a browser, a separate application than telnet, could cause the Apache Web server to log an invalid entry? The command line GET has absolutely nothing to do with any Web browser.
Hmmm...I just tried to reproduce this and couldn't. When I do a GET http://www.yahoo.com from a telnet session, I get the yahoo.com page.
Actually, not being able to reproduce the log entry using the browser would pretty much eliminate the browser as the source of the problem.
Assume my car doesn't start whenever my lights are turned on. I'm not sure I understand how a second car that can't reproduce this problem would eliminate my car as the source of the problem.
Rich
I think you misread what I was saying. You said reproducing it through telnet would eliminate the browser as a possibility. I countered (using your wording, which you made a complete mess of with circularity in your last reply :) ), that that actually has nothing to do with eliminating the browser theory. It only tells us that there are one or more possible explanations.
Dan
Arthur
11-03-2001, 06:04 PM
No one should be able to telnet to the server (you can't technically telnet to a 'site') Of course you can, you just connect on port 80 and send commands complying with the HTTP protocol (GET is a command in that protocol, not a command line command). Telnet just opens a TCP/IP stream, which you usually use to open a shell on port 23, but you can connect to any port.
Of course you can, you just connect on port 80...
Ah...now both Arthur's and Dank's comments make sense. I was thinking of a port 23 connection (which also has a GET command).
Rich
-- Why do drive-up ATM's have braile instructions?
Ah...now both Arthur's and Dank's comments make sense.
Hey now, don't include me among those in the discussion with any knowledge of what's being talked about! I was merely playing loose with logic. :)
Dan
Originally posted by Rich:
If you can reproduce the log entry using telnet, that pretty much eliminates the browser as the source of the problem...
Rich
I would think that in this case, it actually implicates the browser - the browser is doing automatically (and in error) the same thing (connect to a domain but then ask for a URI in a different domain) that you can do manually with telnet.%)
Oh, I see all has been explained - I thought I had read down to the end of the thread, but apparently not.
vBulletin® v3.6.8, Copyright ©2000-2009, Jelsoft Enterprises Ltd.