When using mod_proxy the headers_out already set by other modules (mod_cas, mod_usertrack(?)...) are overwritten by mod_proxy. Therefore, no cookies can be set and these modules can't work. The 2.2 version _does_ save the pre-existing headers_out before modifying them. It would be great if mod_proxy 2.0 could preserve the pre-existing headers_out, just like 2.2 do... Here is a patch against 2.0.59 that backports this 2.2 behaviour : --- proxy_http.c.old 2007-01-17 20:08:19.000000000 +0100 +++ proxy_http.c 2007-01-17 20:12:24.000000000 +0100 @@ -1282,6 +1282,12 @@ return APR_SUCCESS; } +static int addit_dammit(void *v, const char *key, const char *val) +{ + apr_table_addn(v, key, val); + return 1; +} + static apr_status_t ap_proxy_http_process_response(apr_pool_t * p, request_rec *r, proxy_http_conn_t *p_conn, @@ -1302,7 +1308,7 @@ * in the case that the origin told us * to HTTP_CONTINUE */ - + apr_table_t *save_table; /* Get response from the remote server, and pass it up the * filter chain */ @@ -1372,6 +1378,12 @@ /* N.B. for HTTP/1.0 clients, we have to fold line-wrapped headers*/ /* Also, take care with headers with multiple occurences. */ + + /* First, tuck away all already existing cookies */ + save_table = apr_table_make(r->pool, 2); + apr_table_do(addit_dammit, save_table, r->headers_out, + "Set-Cookie", NULL); + r->headers_out = ap_proxy_read_headers(r, rp, buffer, sizeof(buffer), origin); if (r->headers_out == NULL) { @@ -1391,6 +1403,18 @@ return r->status; } + /* Now, add in the just read cookies */ + apr_table_do(addit_dammit, save_table, r->headers_out, + "Set-Cookie", NULL); + + /* and now load 'em all in */ + if (!apr_is_empty_table(save_table)) { + apr_table_unset(r->headers_out, "Set-Cookie"); + r->headers_out = apr_table_overlay(r->pool, + r->headers_out, + save_table); + } + /* can't have both Content-Length and Transfer-Encoding */ if (apr_table_get(r->headers_out, "Transfer-Encoding") && apr_table_get(r->headers_out, "Content-Length")) {
Created attachment 19423 [details] Patch against proxy_http.c 2.0.59
Huh? This looks like a patch that's been in 2.0.x for years!
It was indeed committed in rev 103638 (http://svn.apache.org/viewvc?view=rev&revision=103638), released in 2.0.50, but then removed in rev 104015 (2.0.51) (http://svn.apache.org/viewvc?view=rev&revision=104015). I don't know why.
Interesting. I expect it may have got caught up in branching 2.0/2.2. There were a lot of major improvements in mod_proxy&family, that people felt should be in 2.2 but were too big a change for 2.0. Anyway, it's certainly fixed in the forthcoming releases of current branches, both 2.0 and 2.2.