Re: [PATCH 1.3] Proxied Server:/Date: headers
William Rowe wrote... I'd worked with some interesting java and cgi code which implements proxy behavior, as opposed to using a compiled-in module such as mod_proxy. In order to properly pass on the Server: and Date: headers (which are owned by the origin server), this patch tests for the presence of a Via: header, indicating the response is proxied. If neither r-proxyreq nor a 'Via:' header exist, the server still overrides the Server: and Date: responses, per RFC. Not seeing any other feedback on this but thought I would add my 2 cents. I understand what you are talking about. Allowing CGI to have finer grain control over what headers are ACTUALLY returned with a response has always been an issue with Apache. Only a MODULE really has the API calls for that kind of 'out the door' control and sometimes not even enough... ...but this sound like a real hack. Using 'Via:' to ASSUME anything, much less making it a permanent patch to the production code, just sounds like a bad idea. You just can't depend on anyone actually using 'Via:' at all. The patch might actually create more problems than it solves. Maybe the discussion really should be centered on the classic issue that this problem represents... How can CGI gain better control over the actual 'on the wire' header output? ( Override Server default behavior, when necessary, etc... ). Maybe the OTHER discussion going on about mod_headers is actually RELATED to this. Syntax: Header set|append|add|unset|echo header [value [env=[!]variable]] [persist] Someone who wants to do 'proxy behavior' from CGI and not a module probably SHOULD be able to coordinate the actual return header content by using ENVIRONMENT variables in conjunction with mod_headers. Example... 1. CGI decides ( However it can ) that Server: field should either be changed on the return OR remain the same. 2. CGI supplies the RIGHT 'Server:' header 3. CGI also ( somehow? ) tells core Server to RESPECT the decisions it has made and actually USE the new Server/Date header(s) on the return trip and not default to something else. Some environment variable signal like "Use_the_headers_I_am_giving_you_as_is"? Or maybe what you are talking about here is just some new way for the CGI ( decision maker ) itself to be able to directly set the the r-proxyreq flag BEFORE it 'returns' if/when the CGI decides that needs to be done. Right now... you are right... that's something that only mod_proxy or some other MODULE code can do. Better access to core server variables from CGI? A new API to do that? Don't know. I just think the 'Via:' thing is bad idea and doesn't rise to the level of needing to be a permanent patch. Later... Kevin Original Message from William Rowe... Still hoping for some feedback. Note that this proposal affects anyone who tries to implement a proxy feed from CGI, modperl, tomcat, php, or any other interesting mechanism, where the user can't manipulate the r-proxyreq flag :) Bill Date: Fri, 28 May 2004 13:02:14 -0500 To: [EMAIL PROTECTED] From: "William A. Rowe, Jr." [EMAIL PROTECTED] I'd worked with some interesting java and cgi code which implements proxy behavior, as opposed to using a compiled-in module such as mod_proxy. In order to properly pass on the Server: and Date: headers (which are owned by the origin server), this patch tests for the presence of a Via: header, indicating the response is proxied. If neither r-proxyreq nor a 'Via:' header exist, the server still overrides the Server: and Date: responses, per RFC. Comments appreciated. Bill
Re: [PATCH 1.3] Proxied Server:/Date: headers
Still hoping for some feedback. Note that this proposal affects anyone
who tries to implement a proxy feed from CGI, modperl, tomcat, php,
or any other interesting mechanism, where the user can't manipulate
the r-proxyreq flag :)
Bill
Date: Fri, 28 May 2004 13:02:14 -0500
To: [EMAIL PROTECTED]
From: William A. Rowe, Jr. [EMAIL PROTECTED]
I'd worked with some interesting java and cgi code which implements
proxy behavior, as opposed to using a compiled-in module such as
mod_proxy. In order to properly pass on the Server: and Date: headers
(which are owned by the origin server), this patch tests for the presence
of a Via: header, indicating the response is proxied.
If neither r-proxyreq nor a 'Via:' header exist, the server still overrides
the Server: and Date: responses, per RFC.
Comments appreciated.
Bill
--- src/main/http_protocol.c15 Apr 2004 15:51:51 - 1.335
+++ src/main/http_protocol.c28 May 2004 18:00:10 -
@@ -1544,6 +1544,8 @@
API_EXPORT(void) ap_basic_http_header(request_rec *r)
{
char *protocol;
+const char *datestr = NULL;
+const char *server = NULL;
if (r-assbackwards)
return;
@@ -1569,20 +1571,29 @@
/* output the HTTP/1.x Status-Line */
ap_rvputs(r, protocol, , r-status_line, CRLF, NULL);
-/* output the date header */
-ap_send_header_field(r, Date, ap_gm_timestr_822(r-pool, r-request_time));
+/* keep the set-by-proxy date header, otherwise
+ * generate a new server header */
+if (r-proxyreq || ap_table_get(r-headers_out, Via)) {
+datestr = ap_table_get(r-headers_out, Date);
+
+if (datestr (ap_parseHTTPdate(datestr) == BAD_DATE)) {
+datestr = NULL;
+}
+}
+if (!datestr || !*datestr) {
+datestr = ap_gm_timestr_822(r-pool, r-request_time);
+}
+ap_send_header_field(r, Date, datestr);
/* keep the set-by-proxy server header, otherwise
* generate a new server header */
-if (r-proxyreq) {
-const char *server = ap_table_get(r-headers_out, Server);
-if (server) {
-ap_send_header_field(r, Server, server);
-}
+if (r-proxyreq || ap_table_get(r-headers_out, Via)) {
+server = ap_table_get(r-headers_out, Server);
}
-else {
-ap_send_header_field(r, Server, ap_get_server_version());
+if (!server || !*server) {
+server = ap_get_server_version();
}
+ap_send_header_field(r, Server, server);
/* unset so we don't send them again */
ap_table_unset(r-headers_out, Date);/* Avoid bogosity */
[PATCH 1.3] Proxied Server:/Date: headers
I'd worked with some interesting java and cgi code which implements
proxy behavior, as opposed to using a compiled-in module such as
mod_proxy. In order to properly pass on the Server: and Date: headers
(which are owned by the origin server), this patch tests for the presence
of a Via: header, indicating the response is proxied.
If neither r-proxyreq nor a 'Via:' header exist, the server still overrides
the Server: and Date: responses, per RFC.
Comments appreciated.
Bill--- src/main/http_protocol.c15 Apr 2004 15:51:51 - 1.335
+++ src/main/http_protocol.c28 May 2004 18:00:10 -
@@ -1544,6 +1544,8 @@
API_EXPORT(void) ap_basic_http_header(request_rec *r)
{
char *protocol;
+const char *datestr = NULL;
+const char *server = NULL;
if (r-assbackwards)
return;
@@ -1569,20 +1571,29 @@
/* output the HTTP/1.x Status-Line */
ap_rvputs(r, protocol, , r-status_line, CRLF, NULL);
-/* output the date header */
-ap_send_header_field(r, Date, ap_gm_timestr_822(r-pool, r-request_time));
+/* keep the set-by-proxy date header, otherwise
+ * generate a new server header */
+if (r-proxyreq || ap_table_get(r-headers_out, Via)) {
+datestr = ap_table_get(r-headers_out, Date);
+
+if (datestr (ap_parseHTTPdate(datestr) == BAD_DATE)) {
+datestr = NULL;
+}
+}
+if (!datestr || !*datestr) {
+datestr = ap_gm_timestr_822(r-pool, r-request_time);
+}
+ap_send_header_field(r, Date, datestr);
/* keep the set-by-proxy server header, otherwise
* generate a new server header */
-if (r-proxyreq) {
-const char *server = ap_table_get(r-headers_out, Server);
-if (server) {
-ap_send_header_field(r, Server, server);
-}
+if (r-proxyreq || ap_table_get(r-headers_out, Via)) {
+server = ap_table_get(r-headers_out, Server);
}
-else {
-ap_send_header_field(r, Server, ap_get_server_version());
+if (!server || !*server) {
+server = ap_get_server_version();
}
+ap_send_header_field(r, Server, server);
/* unset so we don't send them again */
ap_table_unset(r-headers_out, Date);/* Avoid bogosity */
