Bug 38550

Summary: Setting headers based on proxied data
Product: Apache httpd-2 Reporter: Rik Rose <apache>
Component: mod_rewriteAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED LATER    
Severity: enhancement CC: apache
Priority: P3 Keywords: MassUpdate
Version: 2.0-HEAD   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Rik Rose 2006-02-07 13:13:43 UTC
mod_rewrite can set headers and cookies based on parts of the request. It would
be good if it could set headers and cookies based on part of the response as
well. In the situation where Apache is being used as a (reverse) proxy in front
of another web application server, this allows for greater flexibility in
setting cookies - a very large gain, if the web application acts as a cookie jar.

The easiest way to implement this is to do make the following changes:
 - Add a new flag to rules, indicating that the rule should only be run AFTER 
   content has been returned
 - Add a "before/after" flag to apply_rewrite_list.
 - In apply_rewrite_list, only run rules with the AFTER flag is the
   before/after flag is set. Do not run rules without the AFTER flag if the
   before/after flag is not set.
 - Add an output filter hook, essentially to run mod_rewrite again, as an
   output filter.
 - Add the new before/after flag to the calls to apply_rewrite_list. The
   original calls to mod_rewrite should all call with the before/after flag set
   to "before", and the call(s) in the output filter hooks should all call with
   the flag set to "after".
 - Edit lookup_header to search for output headers in preference to request
   headers. For correctness, a before/after flag should be inserted for this
   function, to enable looking for output headers only after the response has
   been generated.
Comment 1 André Malo 2006-02-07 14:03:39 UTC
mod_rewrite can only set cookies directly, which is already just a side effect
of the actual task of mod_rewrite - rewriting of incoming URLs. The only other
header which can be set, but only implicitly, is Vary.

I don't think that your suggestion is a good idea. If you want to set headers,
mod_headers is the better choice.

May I ask, what your actual task is?
Comment 2 Rik Rose 2006-02-08 17:36:06 UTC
mod_headers is indeed the correct place to do so, but it's also a far more
difficult place to do so, because mod_headers can not read an existing value to
assign it elsewhere - it can only assign values from the config file. In order
to (want to) use mod_headers the code to read existing headers and cookies to
use as values, like mod_rewrite's %{HTTP_foo} etc would need to be added.

The easiest way to think about what I'm doing is that I'm setting a cookie for
the browser after an application that acts as a cookie jar - think sneaking a
cookie past an anonymising proxy, by disguising it in a header, and rewriting it
back.

I agree, in principal, mod_rewrite is a completely stupid place to do this hack.
On the other hand, it's a very very easy place to do it, as all of the support
code is in place.
Comment 3 William A. Rowe Jr. 2018-11-07 21:08:49 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.