Bug 50525 - Header directive won't edit Location header from ProxyPass or RewriteRule
Summary: Header directive won't edit Location header from ProxyPass or RewriteRule
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_headers (show other bugs)
Version: 2.2.15
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2010-12-28 15:37 UTC by Luke Meyer
Modified: 2018-11-07 21:09 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Meyer 2010-12-28 15:37:15 UTC
mod_header documentation and internet discussion seemed to indicate that I could fix a mistaken Location: header using the Header directive. However, this did not seem to work in the two cases that I tried.

1. ProxyPass:

ProxyPass / http://google.com/
# which of course gets a 301 to www.google.com
Header always edit Location: goo gar
# so we should go to www.gargle.com
Header always add X-Foo: bar
# just put that in to make sure Header was working at all

The response in this case includes these headers:
X-Foo: bar
Location: http://www.google.com/

So, Location was unaffected.

2. RewriteRule

RewriteEngine on
RewriteRule ^.* http://www.foo.com/ [R]
# so everything is redirected to www.foo.com
Header always edit Location: foo bar
# which should modify it to www.bar.com
Header always add X-Foo: bar

The response then includes:
X-Foo: bar
Location: http://www.foo.com/

Again, Location was unaffected.

If the Location header is added with Header, then a later edit does work. But I can't get it to affect proxied responses, which is what I really wanted. The docs don't indicate any reason why this should fail. So either the docs or mod_headers should be fixed.
Comment 1 Eric Covener 2010-12-28 17:33:30 UTC
A workaround is to duplicate your rule and use the same rule with always and onsuccess.
Comment 2 Eric Covener 2010-12-28 18:03:29 UTC
This is quite broken on a number of levels, but maybe can be made better.

Apache uses two locations to store output headers, and currently mod_headers treats one of them as "onsuccess" and another as "always" but this is not how apache modules use them. mod_headers needs to try harder to treat "always" (or some new cop-out option) as "modify both carefully".

When mod_headers is asked to...
  append [always], it still might not choose so well. 
  add/remove [always], it should be able to figure out the right thing
  edit [always], it should try to edit both
Comment 3 Eric Covener 2010-12-28 22:35:37 UTC
I've tried to explain this in a doc update:

http://svn.apache.org/viewvc?view=revision&revision=1053523

But we should keep the bug as a non-doc bug since this stuff is so difficult to use.  I struck out trying to fix mod_headers to really try to interpet "always" with respect to edit/merge/set/add.
Comment 4 Luke Meyer 2010-12-29 08:55:29 UTC
(In reply to comment #1)
> A workaround is to duplicate your rule and use the same rule with always and
> onsuccess.

This does modify the Location header from ProxyPass, so hopefully my problem is solved. Interestingly, it doesn't modify the header if it's from RewriteRule.

Thanks a lot for the explanation about headers being stored in multiple ways. That makes some sense; of course it would be nice if these directives all operated as expected... but I see it's complicated.
Comment 5 William A. Rowe Jr. 2018-11-07 21:09:59 UTC
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.