Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm at the end of my rope and could really use some fresh insight/suggestions.

The problem:

While runing Apache 2.2.3 on Debian Etch, my Apache server frequently sends a request to ITSELF (to the LAST virtual host in the config file) on random incoming HTTP activity directed towards ANY of the 15 virtual hosts I have set up.

I even mirrored my live server to a local virtual box and I get the exact same behavior.

The (trunacated) logs:

[30/Sep/2009:16:44:04 -0400] (Remote-host:) 127.0.0.1 (400) (Request:) "GET /"
[30/Sep/2009:16:44:05 -0400] (Remote-host:) 127.0.0.1 (400) (Request:) "GET /"
[30/Sep/2009:16:47:07 -0400] (Remote-host:) 127.0.0.1 (400) (Request:) "GET /"
[30/Sep/2009:16:47:12 -0400] (Remote-host:) 127.0.0.1 (400) (Request:) "GET /"

The reason I know it's the last virtual host receiving the strange request is the 400-Bad request error above. Turns out my last vhost is SSL enabled and Apache is sending itself a non-SSL request for /.

My vhost config:

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost *:80>
    ServerName one.example.com
</VirtualHost>

<VirtualHost *:80>
    ServerName two.example.com
</VirtualHost>

<VirtualHost *:80>
    ServerName three.example.com
</VirtualHost>

<VirtualHost *:443>
    ServerName secure.example.com
</VirtualHost>

So when you send an HTTP request to one.example.com, (sometimes) the log file for secure.example.com will be as shown above. WEIRD! I ran mod_dumpio and mod_log_forensic, but didn't gain much insight from them.

What in the world could possibly be causing this?

What I know:

  • It is random, and doesn't matter which vhost receives the HTTP request.
  • When I comment out the last vhost, the problem disappears.
  • My Apache, PHP and MySQL setups are very standard.
  • I can only reproduce the strange self-request when requesting PHP + image files rather than .txt, .xml, .html, etc. files.

Edit (The Fix):

In case anyone else stumbles upon this, here is what I did to remedy the situation.

Change the order of my Apache Listen directives:

Listen 192.168.0.199:443
Listen 192.168.0.199:80

Then add a rewrite rule to my FIRST virtual host:

RewriteCond %{REMOTE_ADDR} ^(192\.168\.0\.199|127\.0\.0\.1)$
RewriteCond %{HTTP_USER_AGENT} internal\ dummy\ connection [NC]
RewriteRule .* /apache-internal-dummy-connection/ [R=302,L]

The rewrite rule simply says, "if the remote users' IP address is the same as my web server AND the remote users' agent (browser) contains the words 'internal dummy connection', redirect (302) any request to http://www.example.com/apache-internal-dummy-connection/".

I chose to redirect to a non-existant URI to keep the load down on my server.

Used tail -f on my first vhost log file and it's working fine on both servers.

Hope this helps someone.

share|improve this question
    
+1 , I've been seeing this too in exactly the same scenario that you describe. Its been driving me batty because I scrape the extended status output to look at requests per domain per some interval of time. –  Tim Post Oct 1 '09 at 1:57
    
Yes, those weird requests seem to come randomly, sometimes just one at a time, and sometimes they'll come in three's spread out over 3-8 seconds. It's really strange! Are you also running Debian Etch? –  Jeff Oct 1 '09 at 9:52

4 Answers 4

up vote 1 down vote accepted

The requests are internal dummy connections which Apache uses to affect the status of child processes. They are harmless and the reason the reason that you are seeing your precise behaviour is due to some quirkiness.

The internal process isn't capable of speaking SSL and gets easily confused by the order of your Listen directives. If Listen 443 is defined after Listen 80 then it will attempt to send a non-SSL request to http://localhost:443/, which will hit your default SSL vhost and fail, resulting in the HTTP status code 400.

As far as I'm aware the only workaround is to re-order your Listen directives the other way round.

share|improve this answer
    
That's about the only thing I haven't tried. Is there any documentation you've seen to reference this? In other words, what should I "google" to read more about it? –  Jeff Oct 1 '09 at 17:36
1  
"ìnternal dummy" is the best term to search for. Not very helpful, I know, because it took me ages to remember. The most official documentation can be found here - wiki.apache.org/httpd/InternalDummyConnection –  Dan Carley Oct 1 '09 at 17:42

While I see that your last vhost block is for port 443, I don't see that it's actually configured for SSL. You have to have "SSLEnable On" for starters. Maybe that's the reason you're seeing the "bad request" error...?

share|improve this answer
    
Nah, everything is configured correctly. I kept my config statements short on this post for brevitys' sake. –  Jeff Oct 1 '09 at 17:34

Please note that you can't NameVirtualHost an SSL connection!

http://httpd.apache.org/docs/2.2/vhosts/name-based.html

share|improve this answer
    
Well, you can, but you probably shouldn't. –  Dan Carley Oct 1 '09 at 16:00
    
I'm curious, and not to hijack anything here, but why shouldn't you and what's the fix? –  Jeff Oct 1 '09 at 17:33
    
You can tell apache to do so, but it won't work properly. The SSL negotiation (which requires various parameters from the VirtualHost) happens before the request header makes it across the connection. (Plus, the Apache docs say you can't do it :) –  MikeyB Oct 1 '09 at 17:45
    
Thanks for the info. Again, not to hijack my own thread, but everything has been working perfectly (with ONE exception, Lol) for a few years now. –  Jeff Oct 1 '09 at 17:56
    
That's because you only have one VirtualHost on *:443. At the moment. :) –  MikeyB Oct 1 '09 at 20:37

actually you can use NameVirtualHost + SSL, using SAN (subject-alternative-name) certs..

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.