httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: [PATCH 1.3] Proxied Server:/Date: headers
Date Thu, 03 Jun 2004 16:33:54 GMT

> 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: dev@httpd.apache.org
>From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
>
>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



Mime
View raw message