[email protected] wrote: > --- httpd/httpd/trunk/docs/manual/mod/core.html.en (original) > +++ httpd/httpd/trunk/docs/manual/mod/core.html.en Fri Aug 28 17:39:08 2009 > @@ -2932,6 +2932,14 @@ > <dd>Server sends (<em>e.g.</em>): <code>Server: Apache/2.0.41 > (Unix)</code></dd> > > + <dt><code>ServerTokens Set <em>"String"</em></code></dt> > + > + <dd>Server sends user specified string > + (<em>e.g.</em>): <code>Server: MyWebServer/8.6</code><br /> > + <strong>Note:</strong> The string must be in quotes if > + there are any embedded spaces. > + </dd> > +
Off? That was a bit hard to stomach, and it seems odd that a long standing policy of presenting clients with usable *negotiation* data, unless they choose to patch their server, would be usurped without a decision by the dev@ list to reverse this policy. If it is reversed, I'm fine with disabling it. But unless "Apache Software Foundation httpd Server" *has been patched*, it remains "Apache" for purposes of identifying the server-agent. Unequivocally -1. Now if you wanted to build a descriptive tag representing a combination of modules, etc, with an *additional* token (just as modules add), then ServerTokens Add of an arbitrary token/token representation is reasonable. E.g. Server: Apache/2.2.12 mod_dav/2.2.12 mod_security/1.8.9 JaguNET/1.0.0 is a perfectly reasonable server string. And I have run into the situation where we used cgi to implement a proxy, where the Via, Date and Server were legitimately different than httpd's force-override-behavior. I'd be happy to see changes that permit applications to convey appropriate values to the user-agent, and have proposed this once before. If there is a détente in our rigid control of the Server: tokens, this might be the time to bring it up.
