mod_negotiate sets an Content-Location header that cannot be modified. This is reasoned because it is “protocol critical”. I would still like to be able to choose whether to include a relative URI or an absolute URI that is sent from the header. I fully understand that the server thinks it knows best. But as the protocol supports both ways and it really would not make anything break by having the option of including the absolute URI … Well, I do not see the reason not to let users have that option. The scenario for including an absolute URI being that I would like a way to inform users and search engines of the absolute/preferred URI for a resource. Say I have two domain names—or just a www. and a www.-less version of one domain—the idea being that I would prefer having users and indexes include the absolutely preferred URI with the www. prefix or from the most preferred domain name. Instead of pushing the users/spiders trough a painful 301 redirect, I think it would be a much better practise to simply include an absolute URI to the resource instead. If a user accesses the resource from the preferred host, then serving the relative URI seams to be the best option. SetEnvIfNoCase Host "^!www.preferred.com$" header/content-location=absolute-uri In today’s releases I cannot even unset and manually set the Content-Location header when it is genereated by mod_negotiation. (Or maybe it is mod_dir that makes the header. I am not absolutely sure.) NOTE! I do not know whether this should be filled for the mod_headers component in stead. Someone who knows are encouraged to modify the bug if it is better suited there.
Also Server header cannot be modified: Header unset Server Header set Server "serv" does not works.
(In reply to comment #1) > Also Server header cannot be modified: > > Header unset Server > Header set Server "serv" > > does not works. That is not related to this bug.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.