Re: [PATCH 40026] ServerTokens Off
On Sep 5, 2006, at 09:28, Jeff Trawick wrote: On 8/20/06, Lars Eilebrecht <[EMAIL PROTECTED]> wrote: According to William: > My 2c, let's adopt the patch for three reasons... > > 1. it's an FAQ that would -go away-, less stress for our peer apache > user supporters Is it really an FAQ? Hmm ... the last time it was discussed on the dev list was more than 2.5 years ago. It is definitely a frequently asked question on the support queues of an Apache-based server I work on. It's also frequently asked on #apache on freenode. At least once or twice a day. -- They went to sea in a sieve, they did In a sieve they went to see
Re: [PATCH 40026] ServerTokens Off
On 8/20/06, Lars Eilebrecht <[EMAIL PROTECTED]> wrote: According to William: > My 2c, let's adopt the patch for three reasons... > > 1. it's an FAQ that would -go away-, less stress for our peer apache > user supporters Is it really an FAQ? Hmm ... the last time it was discussed on the dev list was more than 2.5 years ago. It is definitely a frequently asked question on the support queues of an Apache-based server I work on.
Re: [PATCH 40026] ServerTokens Off
On 8/20/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Lars Eilebrecht wrote: > > Apart from that, it's also possible to customize the Server header by > using mod_security which has a configuration directive for this. My 2c, let's adopt the patch for three reasons... 1. it's an FAQ that would -go away-, less stress for our peer apache user supporters giant +1 Attempts to illuminate have failed. The best education will be to see requests for some odd URL with .EXE in the name in the error log of a Unix box with ServerTokens None. 2. it's not required. Right, we're getting religious about some protocol data which is not even required and which we freely admit that people with the skills should just go hack up the source code to remove. 3. it will dissuade folks from adopting thirdparty modules for foolish reasons, sparing those projects to deal only with users who actually plan to take advantage of their real features ;-) That makes sense to me. Meanwhile, it hardly makes sense to have somebody use a third-party module to remove some protocol data that Apache didn't need to add in the first place.
Re: [PATCH 40026] ServerTokens Off
Jeff Trawick wrote:
> On 8/11/06, Sebastian Nohn <[EMAIL PROTECTED]> wrote:
>
>> And now patches against trunk are available too (attached to this mail).
>
> A little more work is required. With this trunk patch and
> Rename existing ap_get_server_version() to ap_get_server_banner()
>
> Change code that builds strings to send on the wire to call
> ap_get_server_banner() instead.
>
> ap_get_server_version() always spits out something like
> "Apache/2.2.4-dev" (AP_SERVER_BASEVERSION AFAICT)
Please find attached a patch which respects and includes your patch from
<[EMAIL PROTECTED]>.
However, because your patch is not yet fully complete, as
ap_get_server_description() and ap_get_server_banner() both call
get_server_version(), this patch with ServerTokens Off still logs "" at
Server startup.
Best regards,
Sebastian Nohn
--
Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany
+49-228-4097103 · http://nohn.net/ · [EMAIL PROTECTED]
http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&fingerprint=on&search=0xD47D55E0
Index: server/mpm/winnt/service.c
===
--- server/mpm/winnt/service.c (revision 438815)
+++ server/mpm/winnt/service.c (working copy)
@@ -436,7 +436,7 @@
/* Time to fix up the description, upon each successful restart
*/
-full_description = ap_get_server_version();
+full_description = ap_get_server_description();
if ((osver.dwPlatformId == VER_PLATFORM_WIN32_NT)
&& (osver.dwMajorVersion > 4)
Index: server/mpm/winnt/mpm_winnt.c
===
--- server/mpm/winnt/mpm_winnt.c(revision 438815)
+++ server/mpm/winnt/mpm_winnt.c(working copy)
@@ -1705,7 +1705,7 @@
/* A real-honest to goodness parent */
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
"%s configured -- resuming normal operations",
- ap_get_server_version());
+ ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
"Server built: %s", ap_get_server_built());
Index: server/mpm/mpmt_os2/mpmt_os2.c
===
--- server/mpm/mpmt_os2/mpmt_os2.c (revision 438815)
+++ server/mpm/mpmt_os2/mpmt_os2.c (working copy)
@@ -207,7 +207,7 @@
int listener_num, num_listeners, slot;
ULONG rc;
-printf("%s \n", ap_get_server_version());
+printf("%s \n", ap_get_server_description());
set_signals();
if (ap_setup_listeners(ap_server_conf) < 1) {
@@ -270,7 +270,7 @@
ap_scoreboard_image->global->restart_time = apr_time_now();
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
"%s configured -- resuming normal operations",
-ap_get_server_version());
+ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf,
"Server built: %s", ap_get_server_built());
#ifdef AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
Index: server/mpm/netware/mpm_netware.c
===
--- server/mpm/netware/mpm_netware.c(revision 438815)
+++ server/mpm/netware/mpm_netware.c(working copy)
@@ -723,7 +723,7 @@
request_count = 0;
ClearScreen (getscreenhandle());
-printf("%s \n", ap_get_server_version());
+printf("%s \n", ap_get_server_description());
for (i=0;iserver_signature == srv_sig_withmail) {
return apr_pstrcat(r->pool, prefix, "",
- ap_get_server_version(),
+ ap_get_server_banner(),
" Server at server->server_admin) ? "" : "mailto:";,
ap_escape_html(r->pool, r->server->server_admin),
@@ -2590,7 +2590,7 @@
"\n", NULL);
}
-return apr_pstrcat(r->pool, prefix, "", ap_get_server_version(),
+return apr_pstrcat(r->pool, prefix, "", ap_get_server_banner(),
" Server at ",
ap_escape_html(r->pool, ap_get_server_name(r)),
" Port ", sport,
@@ -2614,7 +2614,8 @@
SrvTk_MINIMAL, /* eg: Apache/2.0.41 */
SrvTk_OS, /* eg: Apache/2.0.41 (UNIX) */
SrvTk_FULL, /* eg: Apache/2.0.41 (UNIX) PHP/4.2.2 FooBar/1.2b */
-SrvTk_PRODUCT_ONLY /* eg: Apache */
+SrvTk_PRODUCT_ONLY, /* eg: Apache */
+SrvTk_OFF /* eg: Nothing at all */
};
static enum server_token_type ap_server_tokens = SrvTk_FULL;
@@ -2634,11 +2635,21 @@
version->add_string = AP_SERVER_ADD_STRING;
}
-AP_DECLARE(const char *) ap_get_server_version(void)
+static const char *get_server_version(void)
{
return (server_version ? server_version : AP_SERVER_BASEVERSION);
}
+AP_DECLARE(const char *) ap_get_server_description(void)
+{
+return
Re: [PATCH 40026] ServerTokens Off
2006/8/21, Ivan Ristic <[EMAIL PROTECTED]>: > but I do not know how to remove the Server header completly with mod_security. It is not possible to remove the Server header completely. ModSecuritycan only change it to something else. But I guess one could write anoutput filter to remove it. In fact, I seem to recall someonementioning such output filter recently. Now if I could only remember where... Excerpt from a previous mail to this flamewar thread : " It seems that there is a lot of people who were requiring this feature. I've developed a module ( http://modules.apache.org/search.php?id=962 ) that tricks the core of httpd by faking a proxy request in order to make it possible in module-land, to change this HTTP header. " -- *Francois Pesce*
Re: [PATCH 40026] ServerTokens Off
Mads Toftum wrote: +1 - looking at the number of IIS targeted worms that keep hitting my apache installs seem to suggest that obscuring the server name will at most lead to a false sense of security. Besides, if you really care, I'm pretty sure it wouldn't be all that hard to guess what server it is by looking at all the rest of the headers. Looking at the way the TCPIP stack behaves under normal and error conditions. Looking at the way the HTTP server behaves under normal and error conditions. Looking at the way the file serving behaves under normal and error conditions. Looking at the way any scripting technology behaves under normal and error conditions. You can't hide everything and why waste your own CPU cycles trying to imitate another platforms quirks, when you could be serving documents with it. Another major point about OSS security is that it can withstand source code disclosure _AND_ still be secure. Maybe other servers implementations just aren't in the same league of security. Darryl
Re: [PATCH 40026] ServerTokens Off
On Mon, Aug 21, 2006 at 12:34:55AM +0200, Lars Eilebrecht wrote: > Well, when we've had similar discussions in the past they were > usually about argument No. 1, but the consensus was always that > a security-by-obscurity feature in Apache does not make sense. > +1 - looking at the number of IIS targeted worms that keep hitting my apache installs seem to suggest that obscuring the server name will at most lead to a false sense of security. Besides, if you really care, I'm pretty sure it wouldn't be all that hard to guess what server it is by looking at all the rest of the headers. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: [PATCH 40026] ServerTokens Off
On 8/21/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote: Not that I want to use it, but I am just curious about which one that could be. I know that you can hide the presence of mod_security itself from the server header ModSecurity does not advertise itself in the Server header, at least not any more. (It only did that in the very early days, before I realised it was a mistake.) but I do not know how to remove the Server header completly with mod_security. It is not possible to remove the Server header completely. ModSecurity can only change it to something else. But I guess one could write an output filter to remove it. In fact, I seem to recall someone mentioning such output filter recently. Now if I could only remember where... BTW, for all it's worth, I think Apache should support Server header removal/customisation natively. People that want to change/remove the Server header will do that anyway. Apache supporting the feature directly would mean that they will be able to do the job quickly and get on with their lives. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall
Re: [PATCH 40026] ServerTokens Off
On 08/21/2006 12:34 AM, Lars Eilebrecht wrote: > > For offering such an option with Apache I've only seen two arguments: > > 1. Making the server more secure by not revealing any (or fake) >server information. > > 2. Saving bandwidth. > > > Well, when we've had similar discussions in the past they were > usually about argument No. 1, but the consensus was always that > a security-by-obscurity feature in Apache does not make sense. +1, OTH we partially have these security-by-obscurity features as we can reduce what Apache reports in the Server header, by removing the version number and the modules loaded. > > Saving bandwidth is a valid point, but as I already pointed out Does saving 17 bytes per request really change a lot? For the small one pixel pictures that might be true, but for most requests I would guess that this saves less then 1% of the request size. I would guess that cleaning html pages and compressing content gives you much more savings in this case. > in my previous email, it is only relevant to a very very tiny fraction > of Apache users. Those users who run a high-traffic web site usually > use self-compiled, or customized versions of Apache anyway, and for > them it's easy to modify the code themselves to get rid of the Server > header. Given my arguments above +1 to this. > > Apart from that, it's also possible to customize the Server header by > using mod_security which has a configuration directive for this. Not that I want to use it, but I am just curious about which one that could be. I know that you can hide the presence of mod_security itself from the server header, but I do not know how to remove the Server header completly with mod_security. Regards Rüdiger
Re: [PATCH 40026] ServerTokens Off
According to William: > My 2c, let's adopt the patch for three reasons... > > 1. it's an FAQ that would -go away-, less stress for our peer apache > user supporters Is it really an FAQ? Hmm ... the last time it was discussed on the dev list was more than 2.5 years ago. Apart from that, I don't think that it would go away entirely, because I assume (based on the questions I've seen) that many people actually ask about how to change the Server header (and not just about disabling it). ciao... -- Lars Eilebrecht- Reality corrupts. [EMAIL PROTECTED] - Absolute reality corrupts absolutely.
Re: [PATCH 40026] ServerTokens Off
Lars Eilebrecht wrote: > > Apart from that, it's also possible to customize the Server header by > using mod_security which has a configuration directive for this. My 2c, let's adopt the patch for three reasons... 1. it's an FAQ that would -go away-, less stress for our peer apache user supporters 2. it's not required. Advertising it's not even required, the number of installed Apache servers can be derived from the % of servers which do advertise Apache v.s. others that allow users to hide this header, and using that % for the server token blind installations. Clients can default to the lowest common denominator if they aren't able to determine what the server is doing.(*) 3. it will dissuade folks from adopting thirdparty modules for foolish reasons, sparing those projects to deal only with users who actually plan to take advantage of their real features ;-) (*) and fools who -use- the 'feature' can pay the penalty for clients which choose not to trust that the anonymous server is capable of -correctly- serving byterange, compression or other features which conserve server load - but aren't consistently implemented properly by all HTTP/1.1 servers ;-)
Re: [PATCH 40026] ServerTokens Off
On 8/20/06, Lars Eilebrecht <[EMAIL PROTECTED]> wrote: For offering such an option with Apache I've only seen two arguments: 1. Making the server more secure by not revealing any (or fake) server information. 2. Saving bandwidth. 3. Make all the crazy people go away. There may be no valid reason for it, but we're sick of hearing about it so just give it to them so we can get back to real work. As I've said, I don't have a strong opinion in either direction. Joshua.
Re: [PATCH 40026] ServerTokens Off
According to Sebastian Nohn: > I personally think, "ego" is a bad reason for constricting people. This has nothing to do with "ego". In my opinion it is more than appropriate to put a "label" in the form of the Server header onto the Apache HTTP Server. For example, if I buy a car I can usually order it without the exact type information/logos added to the car, but I just cannot order it without any logo of the manufacturer itself. For offering such an option with Apache I've only seen two arguments: 1. Making the server more secure by not revealing any (or fake) server information. 2. Saving bandwidth. Well, when we've had similar discussions in the past they were usually about argument No. 1, but the consensus was always that a security-by-obscurity feature in Apache does not make sense. Saving bandwidth is a valid point, but as I already pointed out in my previous email, it is only relevant to a very very tiny fraction of Apache users. Those users who run a high-traffic web site usually use self-compiled, or customized versions of Apache anyway, and for them it's easy to modify the code themselves to get rid of the Server header. Apart from that, it's also possible to customize the Server header by using mod_security which has a configuration directive for this. ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
Re: [PATCH 40026] ServerTokens Off
Sebastian Nohn wrote: I fear that many users of Apache would actually turn off the Server header for no or for the wrong reasons (which may "harm" our market share), and therefore I'm -1 on including this patch. It would not change apaches market share. If you are talking about netcraft (and similar stats): I personally think, "ego" is a bad reason for constricting people. We have had a config option in PHP for years to completely hide the fact that a site is using PHP. I don't think it has hurt us in any way. Sure, our Netcraft numbers would probably be higher without it and occasionally we see a dip due to some large site turning it off, but isn't this all about writing useful software and not about marketing gimmicks? -Rasmus
Re: [PATCH 40026] ServerTokens Off
Lars Eilebrecht wrote: > Well, this topic pops up every now and then ... mainly because people > want to change/remove the Server header for "security", i.e., > "security by obscurity" reasons. On your web site you point out that > this does not make much sense and I absolutely agree with that. > > So this would be no reason to include the patch ... Are people asking for that over and over again not an argument FOR the patch? > Removing the Server header to save 17 bytes ... well, only very > very few users of Apache would actually really require that in > order so save bandwidth. I know only on who actually does that, > and that's Yahoo. But for such specialized cases you would be > running a manually compiled or even modified Apache anyway > (like Yahoo). > > So I don't see this as a reason to include the patch. According to Netcraft 3% of all webservers don't sent the header, making the no-server-header #3 in Netcraft's list: http://survey.netcraft.com/Reports/0608/ > I fear that many users of Apache would actually turn off the > Server header for no or for the wrong reasons (which may "harm" our > market share), and therefore I'm -1 on including this patch. It would not change apaches market share. If you are talking about netcraft (and similar stats): I personally think, "ego" is a bad reason for constricting people. Sebastian
Re: [PATCH 40026] ServerTokens Off
According to Sebastian: > > I'd like to propose these patches for inclusion: > > > > http://www.nohn.org/blog/uploads/servertokens_off.patch > > http://www.nohn.org/blog/uploads/servertokens_off_documentation.patch > > Patches are now attached by request. > > I'm looking forward for your comments. Well, this topic pops up every now and then ... mainly because people want to change/remove the Server header for "security", i.e., "security by obscurity" reasons. On your web site you point out that this does not make much sense and I absolutely agree with that. So this would be no reason to include the patch ... Removing the Server header to save 17 bytes ... well, only very very few users of Apache would actually really require that in order so save bandwidth. I know only on who actually does that, and that's Yahoo. But for such specialized cases you would be running a manually compiled or even modified Apache anyway (like Yahoo). So I don't see this as a reason to include the patch. I fear that many users of Apache would actually turn off the Server header for no or for the wrong reasons (which may "harm" our market share), and therefore I'm -1 on including this patch. ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
Re: [PATCH 40026] ServerTokens Off
On 8/14/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Jeff Trawick wrote: > > ap_get_server_version() always spits out something like > "Apache/2.2.4-dev" (AP_SERVER_BASEVERSION AFAICT) Plus wiring in the registered module strings? I think that's extraordinarily useful information when walking in blind to a configuration problem, and would hate to lose it. ... So if the 'version' flavor includes the extra modules and long version number tokens, I'm ++1 for the change. No problems here... I'll work up a patch just to distinguish between banner and version. Any subsequent "ServerTokens None" patch would then be a modification to ap_get_server_banner().
Re: [PATCH 40026] ServerTokens Off
Jeff Trawick wrote: > > ap_get_server_version() always spits out something like > "Apache/2.2.4-dev" (AP_SERVER_BASEVERSION AFAICT) Plus wiring in the registered module strings? I think that's extraordinarily useful information when walking in blind to a configuration problem, and would hate to lose it. I've noticed the discrepancy in the win32 service manager as well, since in our mpm we reregister the long description of the service as this current token. So sometimes it's nothing but Apache/2.2 and sometimes it's Apache/2.2.24 moddav 2.2.4 modextrathing 1.5 which is much more interesting as a long description. So if the 'version' flavor includes the extra modules and long version number tokens, I'm ++1 for the change. Bill
Re: [PATCH 40026] ServerTokens Off
On 8/11/06, Sebastian Nohn <[EMAIL PROTECTED]> wrote: And now patches against trunk are available too (attached to this mail). A little more work is required. With this trunk patch and ServerTokens Off, this is logged at startup: [Mon Aug 14 13:54:19 2006] [notice] configured -- resuming normal operations By default: [Mon Aug 14 13:53:45 2006] [notice] Apache/2.3.0-dev (Unix) DAV/2 configured -- resuming normal operations The issue is that ap_get_server_version() is used for multiple uses: a) a banner (for the lack of a better word) to be used on the wire b) a string that tells the version of the server What do folks think about the following change? Rename existing ap_get_server_version() to ap_get_server_banner() Change code that builds strings to send on the wire to call ap_get_server_banner() instead. ap_get_server_version() always spits out something like "Apache/2.2.4-dev" (AP_SERVER_BASEVERSION AFAICT)
Re: [PATCH 40026] ServerTokens Off
Joshua Slive wrote: Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. And my +1 isn't very strong. I have no problem with saying that this small bit of advertising is the tiny price that you pay for using our free software. But just to make this never-ending issue go away, I'd say put it in. I should also be pointed out in the documentation that those thinking of setting it to "Off" for the purpose of security by obscurity (for hiding of implementation and version number) should realize that this concept has no technical merit in the HTTP server situation. Call this an education clause in the documentation which may head off inappropriate usage by less clueful users. With regards to "the price that you pay ..." I take it that you are reading it from the karma equalization policy not in any legal policy since one of the fundamental points of the Apache Foundation is that advertisement is not one of the prices you pay. Darryl
Re: [PATCH 40026] ServerTokens Off
On 8/12/06, Eli Marmor <[EMAIL PROTECTED]> wrote: But if this option is a so strong dream for somebody, the minimum that can be done to help a little, is a strong recommendation against using this option, in the documentation. I'm +1 on the concept for this patch (I haven't reviewed the code). I think that the docs should say something like Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. And my +1 isn't very strong. I have no problem with saying that this small bit of advertising is the tiny price that you pay for using our free software. But just to make this never-ending issue go away, I'd say put it in. Joshua.
Re: [PATCH 40026] ServerTokens Off
Sorry for joining the discussion so lately. This issue was raised several times in this list. It was voted off in all of them, because of several reasons, one of them was not mentioned this time: Apache's strongest marketing point has been always its dominance among the web servers. With about 70% in all of the market researches, from netcraft.co.uk to securityspace.com, Apache became the first option for almost everybody. It's sure that the "Off" option will hurt the statistics of Apache. Many of us will love to see this option going away, because everybody can do it very easily through the source code, as "Yahoo!" and others already did. But if this option is a so strong dream for somebody, the minimum that can be done to help a little, is a strong recommendation against using this option, in the documentation. My English is not great, so I leave the exact words for somebody else, but this recommendation should say that using the Off option is not social, pays bad for the great efforts that Apache's developers put into this project, and should be used only in closed networks or if there is no other choice. Something like "use it only if you know what you are doing". After all, people don't pay anything for the great efforts of the Apache's developers, and crediting Apache is the only nominal "thank" that they can do. Of course, the statistics of Apache is going to suffer even with this warning, but without it - it is going to be even worse. I also think that adding this option requires a new license (2.1?) stating that "You" must mention Apache in this HTTP header, so technically it will be possible to use Off, but not according to the license. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH 40026] ServerTokens Off
Sebastian Nohn wrote:
> Sebastian Nohn wrote:
>
>>I'd like to propose these patches for inclusion:
>>
>> http://www.nohn.org/blog/uploads/servertokens_off.patch
>> http://www.nohn.org/blog/uploads/servertokens_off_documentation.patch
>
> Patches are now attached by request.
>
> I'm looking forward for your comments.
And now patches against trunk are available too (attached to this mail).
Best regards,
Sebastian
Index: server/core.c
===
--- server/core.c (revision 430809)
+++ server/core.c (working copy)
@@ -2708,7 +2708,8 @@
SrvTk_MINIMAL, /* eg: Apache/2.0.41 */
SrvTk_OS, /* eg: Apache/2.0.41 (UNIX) */
SrvTk_FULL, /* eg: Apache/2.0.41 (UNIX) PHP/4.2.2 FooBar/1.2b */
-SrvTk_PRODUCT_ONLY /* eg: Apache */
+SrvTk_PRODUCT_ONLY, /* eg: Apache */
+SrvTk_OFF /* eg: Nothing at all */
};
static enum server_token_type ap_server_tokens = SrvTk_FULL;
@@ -2763,7 +2764,10 @@
*/
static void ap_set_version(apr_pool_t *pconf)
{
-if (ap_server_tokens == SrvTk_PRODUCT_ONLY) {
+if (ap_server_tokens == SrvTk_OFF) {
+ap_add_version_component(pconf, "");
+}
+else if (ap_server_tokens == SrvTk_PRODUCT_ONLY) {
ap_add_version_component(pconf, AP_SERVER_BASEPRODUCT);
}
else if (ap_server_tokens == SrvTk_MINIMAL) {
@@ -2812,6 +2816,9 @@
else if (!strcasecmp(arg, "Prod") || !strcasecmp(arg, "ProductOnly")) {
ap_server_tokens = SrvTk_PRODUCT_ONLY;
}
+else if (!strcasecmp(arg, "Off") ) {
+ap_server_tokens = SrvTk_OFF;
+}
else {
ap_server_tokens = SrvTk_FULL;
}
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (revision 430809)
+++ modules/http/http_filters.c (working copy)
@@ -737,7 +737,10 @@
}
}
else {
-form_header_field(&h, "Server", ap_get_server_version());
+char *server_version = ap_get_server_version();
+if (server_version[0] != '\0') {
+form_header_field(&h, "Server", ap_get_server_version());
+}
}
/* unset so we don't send them again */
Re: [PATCH 40026] ServerTokens Off
Sebastian Nohn wrote:
> I'd like to propose these patches for inclusion:
>
> http://www.nohn.org/blog/uploads/servertokens_off.patch
> http://www.nohn.org/blog/uploads/servertokens_off_documentation.patch
Patches are now attached by request.
I'm looking forward for your comments.
Sebastian
diff -ru httpd-2.0.58/modules/http/http_protocol.c
httpd-2.0.58.new/modules/http/http_protocol.c
--- httpd-2.0.58/modules/http/http_protocol.c 2006-04-24 19:12:21.0
+0200
+++ httpd-2.0.58.new/modules/http/http_protocol.c 2006-07-23
17:53:01.0 +0200
@@ -1280,12 +1280,15 @@
}
}
else {
-form_header_field(&h, "Server", ap_get_server_version());
+char *server_version = ap_get_server_version();
+if (server_version[0] != '\0') {
+form_header_field(&h, "Server", ap_get_server_version());
+}
}
/* unset so we don't send them again */
apr_table_unset(r->headers_out, "Date");/* Avoid bogosity */
-apr_table_unset(r->headers_out, "Server");
+apr_table_unset(r->headers_out, "Server");
}
AP_DECLARE(void) ap_basic_http_header(request_rec *r, apr_bucket_brigade *bb)
diff -ru httpd-2.0.58/server/core.c httpd-2.0.58.new/server/core.c
--- httpd-2.0.58/server/core.c 2006-04-24 19:12:21.0 +0200
+++ httpd-2.0.58.new/server/core.c 2006-07-23 17:07:38.0 +0200
@@ -2436,7 +2436,8 @@
SrvTk_MINIMAL, /* eg: Apache/2.0.41 */
SrvTk_OS, /* eg: Apache/2.0.41 (UNIX) */
SrvTk_FULL, /* eg: Apache/2.0.41 (UNIX) PHP/4.2.2 FooBar/1.2b */
-SrvTk_PRODUCT_ONLY /* eg: Apache */
+SrvTk_PRODUCT_ONLY, /* eg: Apache */
+SrvTk_OFF /* eg: Nothing at all */
};
static enum server_token_type ap_server_tokens = SrvTk_FULL;
@@ -2491,7 +2492,10 @@
*/
static void ap_set_version(apr_pool_t *pconf)
{
-if (ap_server_tokens == SrvTk_PRODUCT_ONLY) {
+if (ap_server_tokens == SrvTk_OFF) {
+ap_add_version_component(pconf, "");
+}
+else if (ap_server_tokens == SrvTk_PRODUCT_ONLY) {
ap_add_version_component(pconf, AP_SERVER_BASEPRODUCT);
}
else if (ap_server_tokens == SrvTk_MINIMAL) {
@@ -2540,6 +2544,9 @@
else if (!strcasecmp(arg, "Prod") || !strcasecmp(arg, "ProductOnly")) {
ap_server_tokens = SrvTk_PRODUCT_ONLY;
}
+else if (!strcasecmp(arg, "Off") ) {
+ap_server_tokens = SrvTk_OFF;
+}
else {
ap_server_tokens = SrvTk_FULL;
}
diff -ru docs/conf/httpd-std.conf.in docs.new/conf/httpd-std.conf.in
--- docs/conf/httpd-std.conf.in 2006-07-23 18:02:40.0 +0200
+++ docs.new/conf/httpd-std.conf.in 2006-07-23 18:10:07.0 +0200
@@ -520,8 +520,9 @@
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
-# Set to one of: Full | OS | Minor | Minimal | Major | Prod
-# where Full conveys the most information, and Prod the least.
+# Set to one of: Full | OS | Minor | Minimal | Major | Prod | Off
+# where Full conveys the most information, and Prod the least. Off will display
+# no information at all.
#
ServerTokens Full
Only in docs.new/conf: httpd-std.conf.in~
diff -ru docs/conf/httpd-win.conf docs.new/conf/httpd-win.conf
--- docs/conf/httpd-win.conf2006-07-23 18:02:40.0 +0200
+++ docs.new/conf/httpd-win.conf2006-07-23 18:06:02.0 +0200
@@ -446,8 +446,9 @@
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
-# Set to one of: Full | OS | Minor | Minimal | Major | Prod
-# where Full conveys the most information, and Prod the least.
+# Set to one of: Full | OS | Minor | Minimal | Major | Prod | Off
+# where Full conveys the most information, and Prod the least. Off will
+# display no information at all.
#
ServerTokens Full
Only in docs.new/conf: httpd-win.conf~
diff -ru docs/manual/mod/core.xml docs.new/manual/mod/core.xml
--- docs/manual/mod/core.xml2006-07-23 18:03:16.0 +0200
+++ docs.new/manual/mod/core.xml2006-07-23 18:08:23.0 +0200
@@ -2792,7 +2792,7 @@
ServerTokens
Configures the Server HTTP response
header
-ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
+ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full|Off
ServerTokens Full
server config
@@ -2832,6 +2832,10 @@
Server sends (e.g.): Server: Apache/2.0.41
(Unix) PHP/4.2.2 MyMod/1.2
+
+ ServerTokens Off
+
+ Server does not send a Server header
This setting applies to the entire server, and cannot be
Only in docs.new/manual/mod: core.xml~
Re: [PATCH 40026] ServerTokens Off
Brian J. France wrote: > > On Aug 2, 2006, at 3:57 AM, William A. Rowe, Jr. wrote: > >> Sebastian Nohn wrote: >>> >>> please take the time to read it before voting against the proposal :) > > I am all for this patch (I know my vote means nothing)! Which brings me to the question what the general process in Apache httpd project after proposing a patch is. Best regards, Sebastian Nohn -- Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany +49-228-4097103 · http://nohn.net/ · [EMAIL PROTECTED] http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&fingerprint=on&search=0xD47D55E0
Re: [PATCH 40026] ServerTokens Off
William A. Rowe, Jr. wrote: > Sebastian Nohn wrote: >> please take the time to read it before voting against the proposal :) > If the response is being forwarded through a proxy, the proxy application MUST > NOT modify the Server response-header. > > I haven't reviewed the patch, but I presume your patch honors this > requirement? Yes. > I've read your comments, agree it's 17 bytes (that you can just as well > remove, > as you point out, by hand.) > > I'm curious - do IE, Firefox or other common clients use the server name tag > as a clue for fixups around aberrant behavior or to enable optimal behavior? As far as I know, Firefox does'nt do anything in this direction. I did'nt find anything in the source either (which is no proof of course). Best regards, Sebastian Nohn -- Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany +49-228-4097103 · http://nohn.net/ · [EMAIL PROTECTED] http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&fingerprint=on&search=0xD47D55E0
Re: [PATCH 40026] ServerTokens Off
If I recall correctly, the part of the core responsible for adding the HTTP header "Server:" is : /* keep the set-by-proxy server header, otherwise * generate a new server header */ if (r- proxyreq != PROXYREQ_NONE) {
server = apr_table_get(r- headers_out, "Server"); if (server) { form_header_field(&h, "Server", server); } } else { form_header_field(&h, "Server", ap_get_server_version());
}It does not look the type of proxyreq (PROXYREQ_PROXY, PROXYREQ_REVERSE or PROXYREQ_RESPONSE), so if httpd is configured as a proxy, if I'm not mistaking about this part of the code, and if you use mod_header, you can change this "Server:" too. (Yes I'm too lazy to do the test right now).
2006/8/3, William A. Rowe, Jr. <[EMAIL PROTECTED]>:
François wrote:>>> If the response is being forwarded through a proxy, the proxy application>> MUST NOT modify the Server response-header.>> I think that if you configure your httpd in a [reverse] proxy mode,
> mod_header allow you to modify "Server:", so it is not a problem if a> new directive allows users to change this, at it could already be> modified with an existing module.if you mean, in a "reverse" proxy mode, you are right. A reverse proxy
deliberately doesn't follow the RFC, it's transparent, and would be entirelyappropriate to modify any headers as if this machine were the origin server.But not in the case of "forward" proxy mode - that's what the RFC spelled out.
-- *Francois Pesce*
Re: [PATCH 40026] ServerTokens Off
François wrote: > >> If the response is being forwarded through a proxy, the proxy application >> MUST NOT modify the Server response-header. > > I think that if you configure your httpd in a [reverse] proxy mode, > mod_header allow you to modify "Server:", so it is not a problem if a > new directive allows users to change this, at it could already be > modified with an existing module. if you mean, in a "reverse" proxy mode, you are right. A reverse proxy deliberately doesn't follow the RFC, it's transparent, and would be entirely appropriate to modify any headers as if this machine were the origin server. But not in the case of "forward" proxy mode - that's what the RFC spelled out.
Re: [PATCH 40026] ServerTokens Off
It seems that there is a lot of people who were requiring this feature.I've developed a module ( http://modules.apache.org/search.php?id=962 ) that tricks the core of httpd by faking a proxy request in order to make it possible in module-land, to change this HTTP header. To wrowe:> If the response is being forwarded through a proxy, the proxy application MUST> NOT modify the Server response-header.I think that if you configure your httpd in a [reverse] proxy mode, mod_header allow you to modify "Server:", so it is not a problem if a new directive allows users to change this, at it could already be modified with an existing module. 2006/8/2, Brian J. France <[EMAIL PROTECTED]>: On Aug 2, 2006, at 3:57 AM, William A. Rowe, Jr. wrote:> Sebastian Nohn wrote: please take the time to read it before voting against the proposal :)I am all for this patch (I know my vote means nothing)! > I've read your comments, agree it's 17 bytes (that you can just as> well remove,> as you point out, by hand.)I have written a protocol output filter that removes the serverheader, but would much rather have a config directive. > I'm curious - do IE, Firefox or other common clients use the server> name tag> as a clue for fixups around aberrant behavior or to enable optimal> behavior?We (Yahoo!) have run for years without sending the Server header and have not had any problem. I think it is more likely a case of theserver detecting the browser and tweaking the output to get aroundbrowser bugs.Brian -- *Francois Pesce*
Re: [PATCH 40026] ServerTokens Off
On Aug 2, 2006, at 3:57 AM, William A. Rowe, Jr. wrote: Sebastian Nohn wrote: please take the time to read it before voting against the proposal :) I am all for this patch (I know my vote means nothing)! I've read your comments, agree it's 17 bytes (that you can just as well remove, as you point out, by hand.) I have written a protocol output filter that removes the server header, but would much rather have a config directive. I'm curious - do IE, Firefox or other common clients use the server name tag as a clue for fixups around aberrant behavior or to enable optimal behavior? We (Yahoo!) have run for years without sending the Server header and have not had any problem. I think it is more likely a case of the server detecting the browser and tweaking the output to get around browser bugs. Brian
Re: [PATCH 40026] ServerTokens Off
Sebastian Nohn wrote: > > please take the time to read it before voting against the proposal :) Please note... If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. I haven't reviewed the patch, but I presume your patch honors this requirement? I've read your comments, agree it's 17 bytes (that you can just as well remove, as you point out, by hand.) I'm curious - do IE, Firefox or other common clients use the server name tag as a clue for fixups around aberrant behavior or to enable optimal behavior? Bill
Re: [PATCH 40026] ServerTokens Off
On Aug 1, 2006, at 11:00 PM, Sebastian Nohn wrote: I'd like to propose these patches for inclusion: http://www.nohn.org/blog/uploads/servertokens_off.patch http://www.nohn.org/blog/uploads/servertokens_off_documentation.patch I know, this is an unwanted topic here. Reasons are described in http://nohn.org/blog/archives/18-Removing-the-Apache-Server- Header.html http://issues.apache.org/bugzilla/show_bug.cgi?id=40026 so please take the time to read it before voting against the proposal :) I don't see anything wrong with it, aside from an incorrectly filed enhancement request as a bug report, but I haven't tested the patch yet. Roy
