From: Matthew P. <mj...@ie...> - 2002-11-08 00:18:47
Attachments:
phpwiki_http_host_patch.txt
|
I've just gotten this bug report from a user of the Debian package of PHPWiki (reproduced in part below; the complete bug report and all subsequent discussion can be found at http://bugs.debian.org/168137). As all good users do, he's even produced a patch (attached) to correct the problem as he sees it. Is this a problem which the PHPWiki authors feel is a real problem? The patch should apply cleanly, and I'm going to apply and test it when I've got a bit more free time, but I thought it best to get this out to the upstream developers ASAP. -- ----------------------------------------------------------------------- #include <disclaimer.h> Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16 ---------- Forwarded message ---------- Date: Thu, 07 Nov 2002 10:02:06 +0100 From: Ulf Rompe <deb...@ro...> phpwiki uses $HTTP_SERVER_VARS['SERVER_NAME'] to build URLs. I believe that $HTTP_SERVER_VARS['HTTP_HOST'] should be used instead. Many systems have more than one name, and often the primary configured name is not resolvable from outside. In my case, the server is normally named "server.internal-nis-domain", but to be accessible via WWW it has an additional DNS entry calles like "server.official-domain.de". SERVER_NAME resolves to the first, unreachable name, whereas HTTP_HOST gives the right one (which has to be correct because it is the name we called to reach the PHP script). Maybe it would be possible to work around the problem by defining a VirtualHost (untested), but I think changing the variable would be the right way because HTTP_HOST is meant for this purpose. |
From: Jeff D. <da...@da...> - 2002-11-08 02:03:59
|
Thanks for passing on the report, Matthew. > Is this a problem which the PHPWiki authors feel is a real problem? I think this is a non-bug. According to the CGI spec (http://hoohoo.ncsa.uiuc.edu/cgi/env.html) SERVER_NAME should be "The server's hostname, DNS alias, or IP address as it would appear in self-referencing URLs." So if SERVER_NAME is not what you want in self-referencing URLs, I say it's an Apache configuration problem. SERVER_NAME can be explicitly set in the apache config file using the ServerName directive. See: http://httpd.apache.org/docs/mod/core.html#servername If he doesn't want to muck with the Apache config, the PhpWiki admin can also explicitly define PhpWiki's SERVER_NAME in the PhpWiki config file (index.php). $HTTP_SERVER_VARS['SERVER_NAME'] is only used as the default when the admin hasn't specified a value for SERVER_NAME in the config file. (The PhpWiki admin is, of course also allowed to put something like define('SERVER_NAME', $_SERVER['HTTP_HOST']); into index.php if that's really what s/he wants.) I'm reluctant to make changes in PhpWiki's auto-config defaults based on problems dealing with cases where the hosts IP does not map to a resolable host-name --- it seems that's what manual configuration is for. As far as what to use for the default, auto-detected case, it's not clear to me that $HTTP_SERVER_VARS['HTTP_HOST'] would work better than $HTTP_SERVER_VARS['SERVER_NAME'] in the majority of cases. Another concern is that, 'HTTP_HOST' comes from the browser (client), passed in one of the Host: header of the HTTP request --- so there may be some security issues involved as well. The real intended use of HTTP_HOST is for use in virtual hosting situations where multiple virtual hosts share the same IP address. Generally, it's used by the server (apache) to determine which virtual host to direct the request to... |
From: Matthew P. <mj...@ie...> - 2002-11-08 02:18:14
|
On Thu, 7 Nov 2002, Jeff Dairiki wrote: > According to the CGI spec (http://hoohoo.ncsa.uiuc.edu/cgi/env.html) > SERVER_NAME should be "The server's hostname, DNS alias, or IP address > as it would appear in self-referencing URLs." Well, that certainly puts the tin hat on it. If that's what we're supposed to be using in self-referential links according to the spec, that kind of answers the question permanently. > SERVER_NAME can be explicitly set in the apache config file > using the ServerName directive. See: > http://httpd.apache.org/docs/mod/core.html#servername Just a question off the topic since it just popped into my head - can you set SERVER_NAME on a per-VHost basis? I should probably just try it, I guess. > If he doesn't want to muck with the Apache config, the PhpWiki admin > can also explicitly define PhpWiki's SERVER_NAME in the PhpWiki config > file (index.php). $HTTP_SERVER_VARS['SERVER_NAME'] > is only used as the default when the admin hasn't specified a > value for SERVER_NAME in the config file. Which is a reasonable alternative. > (The PhpWiki admin is, of course also allowed to put something like > define('SERVER_NAME', $_SERVER['HTTP_HOST']); > into index.php if that's really what s/he wants.) Heh, quite a reasonable way to do it if that's the desired functionality. > As far as what to use for the default, auto-detected case, > it's not clear to me that $HTTP_SERVER_VARS['HTTP_HOST'] would > work better than $HTTP_SERVER_VARS['SERVER_NAME'] in the majority > of cases. It would work, to my way of thinking, from the point of view that if the client has used that name to get to the server in the first place, it would be reasonable to expect it to work for the next request... > Another concern is that, 'HTTP_HOST' comes from the browser > (client), passed in one of the Host: header of the HTTP request --- > so there may be some security issues involved as well. Mmmm... not a security expert, but nothing comes to mind off the top of my head. But trusting anything from the client-side is never recommended... <g> > The real intended use of HTTP_HOST is for use in virtual hosting > situations where multiple virtual hosts share the same IP address. > Generally, it's used by the server (apache) to determine which > virtual host to direct the request to... Which is kinda the reason for my question above - can ServerName be set on a per-VHost basis? If not, you'd need to use HTTP_HOST or manually set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing. Of course, you're going to have to have some sort of separate config for each independent Wiki, but I thought it might save a bit of work to have one less config item to set for each VHost. At the end of the day, though, the CGI spec says "Thou shalt use SERVER_NAME for self-referencing URLs" so, in the absence of anything really show-stopping to the contrary, I'll take the spec's word for it. - Matt |
From: Jeff D. <da...@da...> - 2002-11-08 02:25:49
|
> Which is kinda the reason for my question above - can ServerName be set > on a per-VHost basis? If not, you'd need to use HTTP_HOST or manually > set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing. Yup. You can (and probably should) put a ServerName directive in each <VirtualHost> section of an Apache config file. |
From: Matthew P. <mj...@ie...> - 2002-11-08 02:32:53
|
On Thu, 7 Nov 2002, Jeff Dairiki wrote: > > Which is kinda the reason for my question above - can ServerName be set > > on a per-VHost basis? If not, you'd need to use HTTP_HOST or manually > > set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing. > > Yup. You can (and probably should) put a ServerName directive in each > <VirtualHost> section of an Apache config file. That makes it even easier, then. Thanks. - Matt |
From: Reini U. <ru...@x-...> - 2002-11-08 08:43:24
|
Jeff Dairiki schrieb: >>Which is kinda the reason for my question above - can ServerName be set >>on a per-VHost basis? If not, you'd need to use HTTP_HOST or manually >>set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing. > > > Yup. You can (and probably should) put a ServerName directive in each > <VirtualHost> section of an Apache config file. I'm also against this patch. There's only HTTP_HOST but multiple SERVER_NAME's. I use name-based vhosts extensively. This will break most of my wiki's. It broke the debian user's wiki because of his special server configuration. If he wants to be hidden from outside, well so. If not he has to define a vhost. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |