Hello, 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: <VirtualHost 194.177.116.167:80> 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 [E=REAL_SERVER:$1,P,L] #### Whatever arrives here is handled by this server as a local file under DocumentRoot </VirtualHost> If you need more info let me know. Matteo Fago
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 ! Mike
Hi, 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 mod_proxy. 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 fix... Romain Bourgue
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...
Created attachment 17398 [details] Diff file made against proxy_http.c apache 2.0.55 Make mod_proxy keep the pre-existing headers_in
BTW, this bug is due to mod_proxy, not mod_usertrack
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
This should work with mod_proxy_http. I guess it does not work with mod_proxy_ajp.
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.
Taking the liberty of updating the title of this bug report. It looks like Romain's fix may be reused for mod_proxy_ajp.
Created attachment 21915 [details] Patch against trunk Can you please give the attached patch a try and report back?
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.