mod_proxy and Content-Length
[The cc recipients of this message are those httpd-dev posters who've been involved in the recent C-L discussion(s)] Problems with 2.0.42 and mod_proxy with Content-Length: - 2.0.39 stripped C-L from all HTTP/1.0 responses. - 2.0.40 retained C-L on HTTP/1.0 responses for GETs, but stripped it for HEAD. - 2.0.42 strips C-L from all HTTP/1.0 responses. Do people think that the 2.0.42 behaviour (stripping C-L from all HTTP/1.0 responses) is correct? The messages referenced below would suggest not, but .42 has reverted to .39's behaviour. It's NOT obvious that the present behaviour complies with RFC2616, of which section 13.5.2 states (in part): The Content-Length field of a request or response is added or deleted according to the rules in section 4.4, although section 4.4 is plenty vague about what the rules applicable to a proxy are. Before I consider committing some of our internal resources to start work on a fix for this (the problem has some urgency for us in a specific application, as .42's behaviour is breaking things for a specific automated user agent we use), I wanted to confirm the group's thinking about this... Thanks, Richard References: http://marc.theaimsgroup.com/?l=apache-httpd-devm=103024480807478w=2 http://marc.theaimsgroup.com/?l=apache-httpd-devm=102991563528702w=2 And this long thread: http://marc.theaimsgroup.com/?l=apache-httpd-devm=102769842621987w=2 -- . Richard Reiner, Ph.D. . FSC Internet Corp. . 229 Yonge Street, Toronto, Ontario, Canada M5B 1N9 . Tel: +1 416 921 4280, Fax: +1 416 966 2451 . [EMAIL PROTECTED], http://www.fscinternet.com
Re: [PATCH] WWW-Authenticate header lost when reverse-proxying
[EMAIL PROTECTED] wrote: *** *** 969,974 --- 980,986 */ int status = r-status; r-status = HTTP_OK; + ap_discard_request_body(rp); return status; } } else How does this part fit into the bugfix? (Doesn't seem related to the bug to me, but then I haven't looked at it that closely, just wondering) If we don't discard the request body that accompanied the 401 response, it is still there on the socket when auth succeeds... and is therefore prepended, in it's raw chunked glory, when the actual content page from the origin server is served to the client.
WWW-Authenticate header lost when reverse-proxying
(Correction to previous posting: This error *only* occurs with
`ProxyErrorOverride On'.)
When operating as a reverse proxy, with `ProxyErrorOverride On',
mod_proxy incorrectly fails to pass through the WWW-Authenticate
response header on 401 responses.
It seems the problem is that ap_send_error_response() clears
r-headers_out, while ap_proxy_http_process_response() does not copy
the WWW-Authenticate header into r-err_headers_out.
A patch which fixes this follows. Note that this has NOT received
extensive testing.
*** modules/proxy/proxy_http.c.orig Thu Sep 19 14:47:51 2002
--- modules/proxy/proxy_http.c Thu Sep 19 17:38:36 2002
***
*** 863,868
--- 863,879
}
}
+ if ((r-status == 401) (conf-error_override != 0)) {
+ const char *buf;
+ const char *wa = WWW-Authenticate;
+ if (buf = apr_table_get(r-headers_out, wa)) {
+ apr_table_set(r-err_headers_out, wa, buf);
+ } else {
+ ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+proxy: origin server sent 401 without w-a
header);
+ }
+ }
+
r-sent_bodyct = 1;
/* Is it an HTTP/0.9 response? If so, send the extra data */
if (backasswards) {
***
*** 969,974
--- 980,986
*/
int status = r-status;
r-status = HTTP_OK;
+ ap_discard_request_body(rp);
return status;
}
} else
[PATCH] WWW-Authenticate header lost when reverse-proxying
Apologies for the resend; I omitted to mark this as a [PATCH].
When operating as a reverse proxy, with `ProxyErrorOverride On',
mod_proxy incorrectly fails to pass through the WWW-Authenticate
response header on 401 responses.
It seems the problem is that ap_send_error_response() clears
r-headers_out, while ap_proxy_http_process_response() does not copy
the WWW-Authenticate header into r-err_headers_out.
A patch which fixes this follows. Note that this has NOT received
extensive testing.
*** modules/proxy/proxy_http.c.orig Thu Sep 19 14:47:51 2002
--- modules/proxy/proxy_http.c Thu Sep 19 17:38:36 2002
***
*** 863,868
--- 863,879
}
}
+ if ((r-status == 401) (conf-error_override != 0)) {
+ const char *buf;
+ const char *wa = WWW-Authenticate;
+ if (buf = apr_table_get(r-headers_out, wa)) {
+ apr_table_set(r-err_headers_out, wa, buf);
+ } else {
+ ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+proxy: origin server sent 401 without w-a
header);
+ }
+ }
+
r-sent_bodyct = 1;
/* Is it an HTTP/0.9 response? If so, send the extra data */
if (backasswards) {
***
*** 969,974
--- 980,986
*/
int status = r-status;
r-status = HTTP_OK;
+ ap_discard_request_body(rp);
return status;
}
} else
WWW-Authenticate header lost when reverse-proxying chunked response
The WWW-Authenticate header is being dropped from responses sent by
mod_proxy in reverse proxy mode, when the original server's response
was chunked.
The problem appears to be in ap_http_header_filter() in
modules/http/http_protocol.c, where we have:
if (r-status == HTTP_NOT_MODIFIED) {
apr_table_do((int (*)(void *, const char *, const char *))
form_header_field,
(void *) h, r-headers_out,
Connection,
Keep-Alive,
ETag,
Content-Location,
Expires,
Cache-Control,
Vary,
Warning,
WWW-Authenticate,
Proxy-Authenticate,
NULL);
}
else {
apr_table_do((int (*) (void *, const char *, const char *))
form_header_field,
(void *) h, r-headers_out, NULL);
}
I would think that in the else case at least the WWW-Authenticate
header should be handled. Are there other headers that should also be
handled here?
