Bug 25543

Summary: mod_proxy_ajp overwrites existing response headers
Product: Apache httpd-2 Reporter: Matteo Fago <fago>
Component: mod_proxyAssignee: Apache HTTPD Bugs Mailing List <bugs>
Severity: normal CC: arh14, tysonrudgey
Priority: P3 Keywords: MassUpdate, PatchAvailable
Version: 2.2.8   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Attachments: Diff file made against proxy_http.c apache 2.0.55
Patch against trunk

Description Matteo Fago 2003-12-15 19:27:24 UTC

we have httpd-2.0.48 installed which acts as a reverse proxy with mod_rewrite to
backend servers which runs PHP.
If an user accesses a proxied page the first time that arrives at the site,
mod_usertrack does not set the cookie, although the cookie value appears in the
log. This ends up in having lines referring to the same user with different
cookie values in the log.
This happens also when calling static content (i.e. an html page) from the
backend, so it is not related to PHP.

The test I have made is the following:

1) I created an HTML page on the backend
2) I have removed the cookie that is set by mod_usertrack from my browser
3) I opened the page through the frontend

If I Look at the webserver log, filtering only the page I'm loading, for every
page load a different cookie value appears in the log.
Using Netscape cookie manager I discovered that the cookie is not received at all.

Here is the configuration for the reverse proxy:

    ServerName www.venere.com

    CustomLog logs/venerecom.log combined_plus_webid env=!no_log

     # Cookie tracking
    CookieDomain  .venere.com
    CookieExpires "1 years"
    CookieName WEB_ID
    CookieTracking on

                                            DocumentRoot /home/httpd/venerecom/
     # This is a reverse proxy so proxyrequests should be off
    ProxyRequests off
    RewriteEngine on

    RewriteMap server prg:/etc/httpd/conf/lb/loadbalance.pl

    # Round Robin
    RewriteRule ^/(cgi/.*)$                     to://${server:cgi}/$1
    RewriteRule ^to://([^/]+)/(.*)              http://$1/$2                   
#### Whatever arrives here is handled by this server as a local file under


If you need more info let me know.

Matteo Fago
Comment 1 Mike Corlett 2004-11-23 14:47:53 UTC
Just to add that I have exactly the same problem. Slightly different setup, but
same issue of a new cookie being created for each object requested by the browser ;

Apache Version 2.0.51
OS : Solaris 9 fully patched

I'm not using the ReverseProxyPath function, but using the [P] parameter in my
RewriteRules, which obviously does pretty much the same thing.

Again if you need more information, just yell !

Comment 2 Romain Bourgue 2006-01-06 18:11:23 UTC

I think that I have the same problem with the following situation :
I use the SSO authentication module "mod_cas" to authenticate users on a reverse
proxied site (Apache 2.0.55 debian).

Problem : Everytime mod_cas tries to set a cookie for the user the Set-Cookie
isn't recieved by the user.

Attempt of explanation :
Mod_cas module sets a header_out 'Set-cookie:' _before_ the request is handle by
Then, mod_proxy submits the request to the backend server, take the response and
seems to override all the headers_out before returning them to the user.
(Note : the backend server *doesn't*  send a Set-Cookie)

If I wasn't clear enough, let me know.

I will look into the code to confirm/cancel this explanation and, maybe, find a

Romain Bourgue
Comment 3 Romain Bourgue 2006-01-12 10:22:53 UTC
This problem has been fixed in 2.2.
I made a patch for 2.0.55 that makes mod_proxy to merge the backend_header with
any pre-existing ones instead of replacing them.
With this patch, Set-Cookie headers are kept and forwarded to the user.

I posted it on dev@httpd.apache.org to (re)start a discussion about pre-existing
headers for mod-proxy...
Comment 4 Romain Bourgue 2006-01-12 10:34:51 UTC
Created attachment 17398 [details]
Diff file made against proxy_http.c apache 2.0.55

Make mod_proxy keep the pre-existing headers_in
Comment 5 Romain Bourgue 2006-01-12 10:36:08 UTC
BTW, this bug is due to mod_proxy, not mod_usertrack
Comment 6 Radim Kolar 2006-08-09 19:18:10 UTC
I have apache-2.2.3 and it still don't work in following configuration:  ### proxy rewrite ProxyRequests Off RewriteEngine On RewriteCond  %{REQUEST_URI}    !^/proxy-(status|info) RewriteRule (.*) ajp://localhost:8009/Alexa-0.3/filez$1 [P] ProxyPreserveHost On  ###tracker CookieDomain .filez.com CookieExpires "4 months" CookieTracking On  and no cookies in proxied requests. cookies in /proxy-status|info pages are ok. Its not fixed in Apache-2.2 as stated in bug comments 
Comment 7 Ruediger Pluem 2006-08-09 20:58:30 UTC
This should work with mod_proxy_http. I guess it does not work with mod_proxy_ajp.
Comment 8 Aaron Hamid 2008-05-03 12:06:09 UTC
I am seeing this with our own Apache authentication module (performs essentially like mod_cas) for requests which are proxied via mod_proxy_ajp in httpd 2.2.8.  If our module authenticates the request, and then it is proxied via mod_proxy_ajp, our cookie never comes back out to the client.  My superficial skimming of the source reveals that this code in ajp_header.c, 'ajp_unmarshal_response' function, may be the problem:

rc = ajp_msg_get_uint16(msg, &num_headers);
    if (rc == APR_SUCCESS) {
        r->headers_out = apr_table_make(r->pool, num_headers);
    } else {
        r->headers_out = NULL;
        num_headers = 0;

It looks like the r->headers_out table is being overwritten here, instead of having headers merged into it, as described in previous comments.

Workaround is to use mod_proxy_http instead where this has been apparently fixed already.
Comment 9 Aaron Hamid 2008-05-03 12:15:42 UTC
Taking the liberty of updating the title of this bug report.  It looks like Romain's fix may be reused for mod_proxy_ajp.
Comment 10 Ruediger Pluem 2008-05-03 12:47:46 UTC
Created attachment 21915 [details]
Patch against trunk

Can you please give the attached patch a try and report back?
Comment 11 William A. Rowe Jr. 2018-11-07 21:08:14 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.