php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #37323 SERVER_NAME not following apache directive
Submitted: 2006-05-05 06:00 UTC Modified: 2006-05-05 18:11 UTC
From: jameslporter at gmail dot com Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 5.1.4 OS: Gentoo
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2006-05-05 06:00 UTC] jameslporter at gmail dot com 
Description:
------------
$_SERVER[SERVER_NAME] needs to have the value of ServerName Directive in Apache....it's not..it's using the url (www)...this is definitely not the expected result and makes this variable useless....makes our hostname on our SSL Cert not match.

Reproduce code:
---------------
<?php
echo $_SERVER['SERVER_NAME'];

?>

Expected result:
----------------
http://website.com/

website.com

http://www.website.com/

website.com

Actual result:
--------------
http://website.com/

website.com

http://www.website.com/

www.website.com

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-05-05 16:32 UTC] mike@php.net 
This is what we get from Apache.
 [2006-05-05 16:44 UTC] jameslporter at gmail dot com 
What process should we follow to get this resolved?? I assume if it is an apache problem, then it needs to be sent upstream.
 [2006-05-05 16:52 UTC] mike@php.net 
Well, I somehow doubt there's something to resolve.
I guess you've a ServerAlias directive active.
 [2006-05-05 16:55 UTC] jameslporter at gmail dot com 
Yes, the serveralias is to allow users who type www.website.com to view the site, for our script though it needs to use the ServerName Directive...I shudder to think of the result of someone who uses another server alias of www.websiteother.com and websiteother.com and www.website.com and website.com .....You would have to buy 4 ssl certs...I think I'll convert our site to .NET before I would do that.
 [2006-05-05 17:00 UTC] mike@php.net 
This doesn't have anything to do with the coice of scripting language.

You know that the browser compares the current host name and the one from the cert?
 [2006-05-05 17:05 UTC] jameslporter at gmail dot com 
Yes, thats why we need our login link to have the SERVER_NAME so that the link would be echo '<a href="https://'.$_SERVER[SERVER_NAME].'/index.php';


Then the browser would be on the correct hostname to compare, rather then showing a warning because www.website.com doesn't match website.com



'SERVER_NAME'

    The name of the server host under which the current script is executing. If the script is running on a virtual host, this will be the value defined for that virtual host. 

Hmm, bug or no bug? If this is "bogus" then the documentation needs clarifying.
 [2006-05-05 17:21 UTC] jameslporter at gmail dot com 
<?php
$envs = apache_getenv('Server_Name');
print_r($envs);

?>

This will output www.website.com or website.com as well....I assume that this is truly what Apache reports then....Guess it goes up to them now?
 [2006-05-05 17:34 UTC] mike@php.net 
1.) I doubt they will change anything.

2.) That's just how it is. If you have a certificate for xxx.com you must ensure that users are only accessing xxx.com.
 [2006-05-05 18:01 UTC] jameslporter at gmail dot com 
This is not a bug at all! You simply need to change the UseCanonicalName to on!! With it off it will use the header, with it on it will use the ServerName configuration.

http://www.apacheref.com/ref/http_core/UseCanonicalName.html

Maybe add a note about this in the documentation...I saw a few other bug reports similar to this with no resolution. I'm sure a lot of people get frustrated by this!
 [2006-05-05 18:11 UTC] mike@php.net 
If you want to file a doc bug, please do so.

This is a actully  not a PHP bug, so it has to be marked as bogus.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 04:01:27 2024 UTC