Re: translate_name and/or map_to_storage hooks
On 05/04/07, Sam Carleton [EMAIL PROTECTED] wrote: On 4/4/07, Sam Carleton [EMAIL PROTECTED] wrote: On 3/27/07, Sam Carleton [EMAIL PROTECTED] wrote: On 3/27/07, Issac Goldstand [EMAIL PROTECTED] wrote: More importantly, lets say my module is called mod_coolapp and when I have it installed, you get to it at /coolapp. I want /coolapp to be the equivalent to the index.php and then have say, /coolapp/images be the same as imageHandler.php. Is there any trick to knowing which page is being requested or is it simply a matter of doing a string compare to see if the first part of the string passed the actual URL (/coolapp/) is images? You're going to want to parse/compare the string. The Right Way(tm) to do this would probably be during the translate_name or possibly map_to_storage hooks to separate the URI mapping logic from the actual response processing logic. You totally lost me with the translate_name and map_to_storage, I will have to do some reading on it. Issac, I am not exactly sure how I would leverage either the translate_name hook or map_to_storage hook. The best I can figure is that I should hook translate_name and this is the translation: /coolapp?params -- /coolapp?type=indexparams /coolapp/images?params -- /coolapp?type=imageparams Do I have the right idea? I have been trying to move forward with the assumption that I am on the right track and continue to run unknowns. How do I identify coolapp as the location? In other words, I have this in my httpd.conf: Location /coolapp SetHandler my_cool_app /Location Inside of the translate_name hook, how do I go about determining that /coolapp is the location? I missed out on the start of this conversion so really don't know what you are trying to do, but look at the source code for mod_alias in Apache as an example of how you can match a URI location to a specific resource in a translate name handler. In the case of mod_alias it matches it to a physical direction and applies different meanings to it depend on whether you are using Alias or ScriptAlias style directives. BTW, if all you are wanting to do is translate stuff like: /coolapp?params -- /coolapp?type=indexparams /coolapp/images?params -- /coolapp?type=imageparams why aren't you just using mod_rewrite? Graham
Re: Reverse proxy mode and DAV protocol
Julian, good day. Tue, Apr 03, 2007 at 06:52:59PM +0200, Julian Reschke wrote: Eygene Ryabinkin schrieb: Good day! Sorry for rather long letter, but this is the summary from numerous discuissions and I really tried to make it short. ... Hi. RFC2518bis allows the Destination header to be just an absolute path for exactly that reason (see http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#destination-header). Pardon for my stupideness, but what 'that reason' you are talking about? The previous letter was rather long and I fail to identify the exact point you're commenting. Could you, please, elaborate a bit? So this is really one of the few things why RFC2518bis support would be useful in practice (if clients start to take advantage of it). But even if the 'Destination' is just the absolute path, then in the reversy proxying from the http://frontend/dir-one to the http://backend/some-long-path/dir-two we will still need to rewrite that absolute path. It is not very uncommon to see the reverse proxying for the different absolute paths on the frontend and backend servers: I've seen some that were due to some software weirdness (for example, two proxied Wiki instances that require the /wiki path to be present in both of them) or some legacy configuration that can not be readily changed due to the poor design. Am I missing some point? -- Eygene
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
-Ursprüngliche Nachricht- Von: Mladen Turk Gesendet: Dienstag, 3. April 2007 17:25 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer stickysession=JSESSIONID stickysession=;jsessionid stickysession=MYSESSION would mean: balancer-sticky[0]=JSESSIONID balancer-sticky[1]=;jsessionid balancer-sticky[2]=MYSESSION balancer-sticky_case[0]=1 balancer-sticky_case[1]=1 balancer-sticky_case[2]=1 OTOH stickysession=JSESSIONID [c] stickysession=MYSESSION [E] or perhaps a different notation ... stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION would mean: balancer-sticky[0]=JSESSIONID balancer-sticky[1]=NULL balancer-sticky[2]=MYSESSION balancer-sticky_case[0]=0 balancer-sticky_case[1]=-1 balancer-sticky_case[2]=1 Hm. I am not quite sure if I get your idea right now. So this is what I understand: 1. You want to change sticky in struct proxy_balancer from const char *sticky to something like const char *sticky[MAX_ENTRIES] Additionally you want to add something like int sticky_case[MAX_ENTRIES] to struct proxy_balancer, right? 2. If balancer-sticky_case[ ] == 1 you want to do a case sensitive search whereas if balancer-sticky_case[ ] == 0 you want to do a case insensitive search. 3. stickysession settings with [C] or [c] are always put in balancer-sticky[0] stickysession settings with [P] or [p] are always put in balancer-sticky[1] stickysession settings with [E] or [e] are always put in balancer-sticky[2] I does not matter in which order you configure this. So stickysession=JSESSIONID [c] stickysession=MYSESSION [E] and stickysession=MYSESSION [E] stickysession=JSESSIONID [c] both would result in balancer-sticky[0]=JSESSIONID balancer-sticky[1]=NULL balancer-sticky[2]=MYSESSION 4. You will pass balancer-sticky[0] as the name parameter to get_cookie_param and balancer-sticky[1] as the name parameter to get_path_param. 5. What do you do if balancer-sticky[ ] is NULL? Skip the search? 6. You said that cite In case the params are omitted the behavior would be as follows: stickysession=JSESSIONID - balancer-sticky-[0] stickysession=;jsessionid - balancer-sticky-[1] stickysession=FOO - balancer-sticky-[2] /cite Why is FOO stored in balancer-sticky-[2]? Is it because stickysession=FOO is the 3rd occurrence of stickysession for this worker or is it because of the name FOO? 7. What is the purpose of [E] [e]? Where will you search for balancer-sticky[2]? In r-subprocess_env? Regards Rüdiger
Re: [PATCH] ProxyAddXHeaders for mod_proxy
Hi, any commens/objections on this patch? On 2/28/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote: Hi, list, attaching same patch with small correction to the one submitted previously (was unnecessary double check for PROXYREQ_REVERSE). Patch is for httpd-2.2.x branch. On 2/28/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote: Hi list, for those of us who are using Apache HTTPD as a internet proxy (a combination of forward and reverse proxy modes) it's important that requests going to the remote servers (which are not known backends but anonymous boxes in this case) would look the same independently whether the original request came in reverse or forward fashion. Currently mod_proxy_http adds X-Forwarded-* headers unconditionally when we have a reverse proxy request and never for forward proxy requests. Attached patch adds a new ProxyAddXHeaders directive with a possible options of On|Off|ReverseOnly, later option leaving the default in order not to break compatibility with current configurations. With this option it is possible to always add X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server headers for both reverse and forward proxy modes, for reverse proxy only or not to add them at all. Comments and suggestions are welcome. -- Dziugas Baltrunas -- Dziugas Baltrunas -- Dziugas Baltrunas http://dziugas.baltrunas.lt/
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Mladen Turk wrote: ... or perhaps a different notation ... stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION I like that much more - these flags like [C] rather raise questions like can I add multiple of them?. What about this?: stickysession The attribute can occur multiple times within a Balancer directive. The session identifier is searched in the sequence of the occurrence of these attributes. Each value modifier can be preceded by one of the modifiers (Cookie|Path|Env) followed by a colon, meaning that the identifier is only searched as a Cookie, an URL path element or in the environment. Without a modifier, the identifier will be searched in both the path and the cookie. (backward compatibility). The search for the identifier is case-sensitive. Regards, Georg
Re: [PATCH] ProxyAddXHeaders for mod_proxy
On Wed, 4 Apr 2007 12:08:15 +0300 Dziugas Baltrunas [EMAIL PROTECTED] wrote: Hi, any commens/objections on this patch? Hmmm ... not sure I understand the problem you're fixing. Currently mod_proxy_http adds X-Forwarded-* headers unconditionally when we have a reverse proxy request and never for forward proxy requests. I'm guessing this is the crux of your point. In the source code is a comment headed Privacy Note, comprising three paragraphs explaining this behaviour. Perhaps it would be useful if you could address that comment directly. Also useful would be if you could explain what information you want is actually being lost in a forward proxy (if indeed that is your underlying problem)? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [PATCH] ProxyAddXHeaders for mod_proxy
Hi, Nick, if you recall my initial paragraph, I'm here to address the configuration of httpd acting as a generic HTTP proxy which is able to handle both a standard (forward proxy mode) and transparent (reverse proxy mode) proxy requests. This is the same what other proxy servers (like Squid) do. For this to achieve I use 'ProxyRequests On' together with couple of mod_rewrite rules with [P] flag (but not ProxyPass rules since every remote host needs to be proxied). The problem is that with current mod_proxy_http outgoing http request is dependant on how the original request was made to httpd. If original request was in forward fashion, no X-Forwarded-* headers are added to the outgoing request. Otherwise, for reverse proxy requests Privacy Note comes into play and additional X-Forwarded-* headers become visible (i.e. added by httpd) for remote hosts. The intention was not to distinguish the way on how the original request was made and stay consistent (that is, always add some headers or never) when forwarding the request to a remote host. I hope now the problem should be more clear. On 4/4/07, Nick Kew [EMAIL PROTECTED] wrote: On Wed, 4 Apr 2007 12:08:15 +0300 Dziugas Baltrunas [EMAIL PROTECTED] wrote: Hi, any commens/objections on this patch? Hmmm ... not sure I understand the problem you're fixing. Currently mod_proxy_http adds X-Forwarded-* headers unconditionally when we have a reverse proxy request and never for forward proxy requests. I'm guessing this is the crux of your point. In the source code is a comment headed Privacy Note, comprising three paragraphs explaining this behaviour. Perhaps it would be useful if you could address that comment directly. Also useful would be if you could explain what information you want is actually being lost in a forward proxy (if indeed that is your underlying problem)? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ -- Dziugas Baltrunas http://dziugas.baltrunas.lt/
Re: Reverse proxy mode and DAV protocol
Eygene Ryabinkin schrieb: Julian, good day. Tue, Apr 03, 2007 at 06:52:59PM +0200, Julian Reschke wrote: Eygene Ryabinkin schrieb: Good day! Sorry for rather long letter, but this is the summary from numerous discuissions and I really tried to make it short. ... Hi. RFC2518bis allows the Destination header to be just an absolute path for exactly that reason (see http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#destination-header). Pardon for my stupideness, but what 'that reason' you are talking about? The previous letter was rather long and I fail to identify the exact point you're commenting. Could you, please, elaborate a bit? Sorry. What I meant by reason was the fact that the Destination header (and some aspects of the If header) require absolute URIs, which is problematic when there's a reverse proxy in the transmission path. All the issues around to rewrite or not to rewrite headers go away once these headers use absolute paths (well, as long as the reverse proxy doesn't also rewrite paths, but I would claim that this is nearly impossible to get right with WebDAV). So this is really one of the few things why RFC2518bis support would be useful in practice (if clients start to take advantage of it). But even if the 'Destination' is just the absolute path, then in the reversy proxying from the http://frontend/dir-one to the http://backend/some-long-path/dir-two we will still need to rewrite that absolute path. It is not very uncommon to see the reverse Right (see above). But if you also rewrite paths, you will also need to rewrite all multistatus response bodies. Thus is why I assumed nobody is traing that. proxying for the different absolute paths on the frontend and backend servers: I've seen some that were due to some software weirdness (for example, two proxied Wiki instances that require the /wiki path to be present in both of them) or some legacy configuration that can not be readily changed due to the poor design. Am I missing some point? I haven't seen reverse proxying with path rewriting working for WebDAV so far. My assumption was that the easy variant (host/port) is already hard enough, and the intent of those changes in RFC2518bis is to make at least this case simpler. Best regards, Julian
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Plüm wrote: 1. You want to change sticky in struct proxy_balancer from const char *sticky to something like const char *sticky[MAX_ENTRIES] Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) Why is FOO stored in balancer-sticky-[2]? Is it because stickysession=FOO is the 3rd occurrence of stickysession for this worker or is it because of the name FOO? Because it's a third occurrence. This is to keep the compatibility with current configurations users may have. In case one is not present it will be skipped during the find_session_route. 7. What is the purpose of [E] [e]? Where will you search for balancer-sticky[2]? In r-subprocess_env? Needs to be added. (a simple check for r-subprocess_env) Regards, Mladen.
Re: Reverse proxy mode and DAV protocol
Julian, Wed, Apr 04, 2007 at 01:12:54PM +0200, Julian Reschke wrote: Pardon for my stupideness, but what 'that reason' you are talking about? The previous letter was rather long and I fail to identify the exact point you're commenting. Could you, please, elaborate a bit? Sorry. What I meant by reason was the fact that the Destination header (and some aspects of the If header) require absolute URIs, which is problematic when there's a reverse proxy in the transmission path. All the issues around to rewrite or not to rewrite headers go away once these headers use absolute paths (well, as long as the reverse proxy doesn't also rewrite paths, but I would claim that this is nearly impossible to get right with WebDAV). Ahh, OK, thanks for the clarification. I had just tried to do path rewriting and I see that things are bad: I am using Git over HTTP and it fails badly with the path rewriting. May be will try to understand why, but I am not sure. So, your point is that Apache should make no attempts to rewrite the 'Destination' header for DAV and clients should use absolute paths for DAV. Or we still need 'Destination' rewriting? In the reverse proxy mode, I mean. Thank you! -- Eygene
Re: Reverse proxy mode and DAV protocol
ons 2007-04-04 klockan 13:12 +0200 skrev Julian Reschke: What I meant by reason was the fact that the Destination header (and some aspects of the If header) require absolute URIs, which is problematic when there's a reverse proxy in the transmission path. All the issues around to rewrite or not to rewrite headers go away once these headers use absolute paths (well, as long as the reverse proxy doesn't also rewrite paths, but I would claim that this is nearly impossible to get right with WebDAV). Rewriting is nearly impossible to get right. Even when limited to simple rewrites of just the host component. There is many aspects of HTTP and HTTP applications which depend on the URIs being known on both sides (client and server), and the more rewrites you do the higher the risk that some of these is overlooked and things starts to break. Most reverse proxies fail even the simple host:port based rewrites, forgetting or wrongly mapping the internal URIs in some random headers (i.e. Location, Content-Location, Destination, etc) or generated response entities. WebDAV in particular has a lot of URIs embedded in generated XML request/response entities. If you do rewrite then you better make sure you have a clear view of how the backend URIs should be mapped back to external URIs, and make sure your rewrites is applied on the complete HTTP messages headers body, both requests and responses, and not just the request line. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Thanks for the clarifications. -Ursprüngliche Nachricht- Von: Mladen Turk Gesendet: Mittwoch, 4. April 2007 13:36 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer Plüm wrote: 1. You want to change sticky in struct proxy_balancer from const char *sticky to something like const char *sticky[MAX_ENTRIES] Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. Why is FOO stored in balancer-sticky-[2]? Is it because stickysession=FOO is the 3rd occurrence of stickysession for this worker or is it because of the name FOO? Because it's a third occurrence. This is to keep the compatibility with current configurations users may have. In case one is not present it will be skipped during the find_session_route. 7. What is the purpose of [E] [e]? Where will you search for balancer-sticky[2]? In r-subprocess_env? Needs to be added. (a simple check for r-subprocess_env) But r-subprocess_env is a table and apr_table_get is never case sensitive. So the case parameter does not make sense for environment variables. To be honest I do not understand why we need the case parameter at all (also for cookie and path). I did not understand the hint you gave regarding PHP and ASP on Jean-Frederic's question on the same matter. Regards Rüdiger
Re: [PATCH] ProxyAddXHeaders for mod_proxy
On Feb 28, 2007, at 11:59 AM, Dziugas Baltrunas wrote: Hi, list, attaching same patch with small correction to the one submitted previously (was unnecessary double check for PROXYREQ_REVERSE). Patch is for httpd-2.2.x branch. Patches should be against trunk. Once approved and proven in the trunk environ, then they may be proposed for backporting to 2.2.x
Help needed track down bug in mod_auth_xradius
Hi
I recently installed a module called mod_auth_xradius on my server.
This module is available from :-
http://www.outoforder.cc/projects/apache/mod_auth_xradius/
It provides authentication against RAIDUS which is exaclty what
I need but unfortunately I have found a bug which is causing me problems.
I tried to contact the author but have had no response and the bug has
been sat in their bug tracking system for several months. I am not an
expert programmer but I do know a little and I wondered if the folks
on this mailing list would be able to help me track down the bug?
The bug is essentially that the module fails if I specify more than
one RADIUS server in my configuration. This is the link to the
outoforder bug tracker:
http://issues.outoforder.cc/view.php?id=43
Here are the details :-
When I configure my directories like this it works fine :-
Location /content
Options Indexes FollowSymLinks ExecCGI
AuthXRadiusRetries 5
AuthXRadiusTimeout 2
AuthXRadiusAddServer 192.168.1.10 mysecret1
AuthName RADIUS
AuthBasicProvider xradius
AuthType basic
AuthPlainAuthoritative off
AuthBasicAuthoritative off
require valid-user
/Location
But when I add a second server entry like this the program fails :-
Location /content
Options Indexes FollowSymLinks ExecCGI
AuthXRadiusRetries 5
AuthXRadiusTimeout 2
AuthXRadiusAddServer 192.168.1.10 mysecret1
AuthXRadiusAddServer 192.168.1.11 mysecret2
AuthName RADIUS
AuthBasicProvider xradius
AuthType basic
AuthPlainAuthoritative off
AuthBasicAuthoritative off
require valid-user
/Location
I have had a look through the source code and I think this is the area
where the failure occurs :-
int xrad_run_auth_check(request_rec* r, const char* user,
const char* password)
{
int i;
int rc;
int can_cache = 0;
int ret = HTTP_UNAUTHORIZED;
struct xrad_handle* rctx = NULL;
xrad_server_info *sr;
apr_md5_ctx_t md5ctx;
char* digest = NULL;
xrad_dirconf_rec *dc = ap_get_module_config(r-per_dir_config,
auth_xradius_module);
xrad_serverconf_rec *sc =
ap_get_module_config(r-server-module_config,
auth_xradius_module);
..snip...
rctx = xrad_auth_open();
/* Loop through the array of RADIUS Servers, adding them to the
rctx object */
sr = (xrad_server_info *) dc-servers-elts;
for (i = 0; i dc-servers-nelts; ++i) {
rc = xrad_add_server(rctx, sr[i].hostname, sr[i].port, sr[i].secret,
dc-timeout, dc-maxtries);
if (rc != 0) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
xradius: Failed to add server '%s:%d': (%d) %s,
sr[i].hostname, sr[i].port, rc,
xrad_strerror(rctx));
goto run_cleanup;
}
}
The Failed to add server error shown above is the error I see when
the module fails.
From the header files, here are the structs :-
/* Simple Repsersentation of a RADIUS Server */
typedef struct {
/* Port number of the RADIUS Server*/
apr_port_t port;
/* Hostname of the RADIUS Server */
char* hostname;
/* Shared Secert for the RADIUS Server */
const char* secret;
} xrad_server_info;
/* Directory Configuration Structure */
typedef struct
{
/* Array of xrad_server_info for this directory */
apr_array_header_t* servers;
/* How long to wait for a reply from any server */
int timeout;
/* How many attempts to transmit the Authentication Request */
int maxtries;
/* Should we reject any requests with a blank password */
int reject_blank;
} xrad_dirconf_rec;
I have tried running the server in GDB and this is the sort of things
I am seeing :-
(gdb) n
131 for (i = 0; i dc-servers-nelts; ++i) {
(gdb) n
132 rc = xrad_add_server(rctx, sr[i].hostname, sr[i].port,
sr[i].secret,
(gdb) print sr[1].hostname
$10 = 0x2e343431 Address 0x2e343431 out of bounds
(gdb) print sr[0].hostname
$11 = 0x8140714 horitative
(gdb) print sr[0].port
$12 = 1812
(gdb) print sr[0].secret
$13 = 0x8140610 192.168.1.11
(gdb) print sr[1].hostname
$14 = 0x2e343431 Address 0x2e343431 out of bounds
(gdb) print sr[1].port
$15 = 1568
(gdb) print sr[1].secret
$16 = 0x312e3233 Address 0x312e3233 out of bounds
(gdb) print dc-servers-nelts
$17 = 2
As can be seen here the data looks to be jumbled up. It looks like
bits of the data are there but sr[0].hostname (first server address)
contains some other part of my apache config. The correct information for
sr[1].hostname (second server address) can actually be seen at the
memory location pointed to by print sr[0].secret.
Could anyone on this mailing list advise what might be going wrong
here?
Thanks
Ben Thompson
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On Apr 4, 2007, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. Since the whole idea of loadable lb method via providers implies an external API to do this, I consider it a public API. But r-subprocess_env is a table and apr_table_get is never case sensitive. So the case parameter does not make sense for environment variables. To be honest I do not understand why we need the case parameter at all (also for cookie and path). I did not understand the hint you gave regarding PHP and ASP on Jean-Frederic's question on the same matter. FWIW, neither did I.
Re: Reverse proxy mode and DAV protocol
Eygene Ryabinkin schrieb: Julian, Wed, Apr 04, 2007 at 01:12:54PM +0200, Julian Reschke wrote: Pardon for my stupideness, but what 'that reason' you are talking about? The previous letter was rather long and I fail to identify the exact point you're commenting. Could you, please, elaborate a bit? Sorry. What I meant by reason was the fact that the Destination header (and some aspects of the If header) require absolute URIs, which is problematic when there's a reverse proxy in the transmission path. All the issues around to rewrite or not to rewrite headers go away once these headers use absolute paths (well, as long as the reverse proxy doesn't also rewrite paths, but I would claim that this is nearly impossible to get right with WebDAV). Ahh, OK, thanks for the clarification. I had just tried to do path rewriting and I see that things are bad: I am using Git over HTTP and it fails badly with the path rewriting. May be will try to understand why, but I am not sure. So, your point is that Apache should make no attempts to rewrite the 'Destination' header for DAV and clients should use absolute paths for DAV. Or we still need 'Destination' rewriting? In the reverse proxy mode, I mean. Thank you! I'd say Path rewriting is very hard, host rewriting is possible. With RFC2518bis, clients can use absolute paths in some places where before an absolute URI was required. This makes host rewriting much easier, but of course that change needs to get deployed. 1) Servers, such as Apache/moddav should start supporting absolute paths in the Destination and If headers ASAP. That's a backwards compatible change and should be easy to deploy. Unfortunately, there's no simple way to check whether a server allows path notation, except by explicitly checking for DAV compliance level 3 (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#rfc.section.18.3). 2) Clients should use absolute paths as soon as they see that the remote server allows this. Of course all of this is of little value until widely deployed servers/clients start using it. Best regards, Julian
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Plüm wrote: Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. The other solution is to keep that in balancer-sticky separated by / (think %2f is unacceptable char anyhow) and do a strtok inside find_session_route. That way one could have N session cookie/path identifiers. so: stickysession=JSESSIONID/;jsessionid or: stickysession=JSESSIONID stickysession=;jsessionid would have in balancer-sticky=JSESSIONID/;jsessionid inside find_session route do a strtok and iterate until null or cookie|path found. But r-subprocess_env is a table and apr_table_get is never case sensitive. The case sensitivity was just an idea as well as env. If you guys think it's not needed fine with me. Regards, Mladen.
Re: Reverse proxy mode and DAV protocol
Julian, Wed, Apr 04, 2007 at 03:22:53PM +0200, Julian Reschke wrote: So, your point is that Apache should make no attempts to rewrite the 'Destination' header for DAV and clients should use absolute paths for DAV. Or we still need 'Destination' rewriting? In the reverse proxy mode, I mean. Thank you! I'd say Path rewriting is very hard, host rewriting is possible. So, if Apache will be able to do the rewriting in its modules, then it should try. OK, thank you. 1) Servers, such as Apache/moddav should start supporting absolute paths in the Destination and If headers ASAP. Again, talking about the current situation when URI are absolute: do you think that 'If' header automatical rewriting is possible and viable for the Apache's modules? I see no technical problems in such rewriting, but may be I am missing something. Thank you! -- Eygene
Re: Reverse proxy mode and DAV protocol
Eygene Ryabinkin schrieb: Julian, Wed, Apr 04, 2007 at 03:22:53PM +0200, Julian Reschke wrote: So, your point is that Apache should make no attempts to rewrite the 'Destination' header for DAV and clients should use absolute paths for DAV. Or we still need 'Destination' rewriting? In the reverse proxy mode, I mean. Thank you! I'd say Path rewriting is very hard, host rewriting is possible. So, if Apache will be able to do the rewriting in its modules, then it should try. OK, thank you. 1) Servers, such as Apache/moddav should start supporting absolute paths in the Destination and If headers ASAP. Again, talking about the current situation when URI are absolute: do you think that 'If' header automatical rewriting is possible and viable for the Apache's modules? I see no technical problems in such rewriting, but may be I am missing something. Thank you! If header rewriting should be possible, as long as the code doing the rewriting does the rewriting carefully (for instance, scanning for .* will probably not be good enough...). Best regards, Julian
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote: Plüm wrote: Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. The other solution is to keep that in balancer-sticky separated by / (think %2f is unacceptable char anyhow) and do a strtok inside find_session_route. Hmmm... I like this idea. Not sure about the use of '/' as the delim (simply because of its other meanings) but that's secondary. Of course, we can't use strtok, since sticky is a const char and we can't be shoving NULLs in there :)
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 4. April 2007 16:16 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote: Plüm wrote: Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. The other solution is to keep that in balancer-sticky separated by / (think %2f is unacceptable char anyhow) and do a strtok inside find_session_route. Hmmm... I like this idea. Not sure about the use of '/' as the delim (simply because of its other meanings) but that's secondary. Of course, we can't use strtok, since sticky is a const char and we can't be shoving NULLs in there :) Plus does it make sense to split the sticky string everytime we search for a route? From my performance feeling this split should be done during configuration time. How about adding either a const char * some_name[FIXED_VALUE] or an apr_array_header_t * to the end of struct proxy_balancer to store the results of the split and setting sticky = some_name[last_non_null_entry] for backward compatibility? Regards Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Plüm wrote: Plus does it make sense to split the sticky string everytime we search for a route? From my performance feeling this split should be done during configuration time. We can use the NUL separated double NUL terminated string. Then a part is start + strlen(start) Regards, Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On Apr 4, 2007, at 10:27 AM, Plüm, Rüdiger, VF-Group wrote: Hmmm... I like this idea. Not sure about the use of '/' as the delim (simply because of its other meanings) but that's secondary. Of course, we can't use strtok, since sticky is a const char and we can't be shoving NULLs in there :) Plus does it make sense to split the sticky string everytime we search for a route? From my performance feeling this split should be done during configuration time. Agreed... It doesn't change. How about adding either a const char * some_name[FIXED_VALUE] or an apr_array_header_t * to the end of struct proxy_balancer to store the results of the split and setting sticky = some_name[last_non_null_entry] for backward compatibility? We already have an existing context we could overload or simply append another element to the struct. Of course, doing that really confuses the whole issue, since we're doing all these weird things to get around changing sticky from a const char* to a apr_array_header_t*... Sooo... how about in trunk making it right (sticky - apr_array_header_t*) and in 2.2 appending sticky_table (apr_array_header_t*)...
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 10:48:58AM -0400, Eric Covener wrote: There's a simple patch attached to the report which tells httpd to keep its hands off ap_is_HTTPD_REDIRECT e.g. 3xx. Given the description of ProxyErrorOverride I wouldn't think expectations would be that 3xx responses would be overridden. That's my expectation too. Whatever people argue, I've shown in this comment: http://issues.apache.org/bugzilla/show_bug.cgi?id=39245#c11 that it's a change in behaviour since 2.0.x. The actual patch on the report might be out of date for trunk. Try the ones on http://issues.apache.org/bugzilla/show_bug.cgi?id=41601 (which I filed but closed as a dupe of the above). Though I've not checked them recently. They're making the same change. I had been meaning to chase this (and the two other bugs I found in this area of code whilst investigating - see later comments in the report). Unfortunately I'm about to go on holiday for three weeks and shall be staying far away from computers! Happy to help when I'm back though. Regards -- Stuart Children http://terminus.co.uk/
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, 4 Apr 2007 10:48:58 -0400
Eric Covener [EMAIL PROTECTED] wrote:
Can any proxy gurus reconsider this bug status?
Hmmm, I have some recollection of debating this before,
presumably without reaching any consensus for change.
-if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status)) {
+if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status) || ap_is_HTTP_REDIRECT(r-status)) {
I don't think we could accept that, because it breaks existing
behaviour someone might be relying on.
What I'd suggest is giving conf-error_override a numeric value
rather than an On/Off flag, and checking
r-status conf-error_override
That way we'll get existing behaviour with it set to 300 (so we
can alias On to that), and get the behaviour you want with 400
(which could perhaps be given another alias).
Any objections to that?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: ProxyErrorOverride and redirects (PR 39245)
On 4/4/07, Nick Kew [EMAIL PROTECTED] wrote:
On Wed, 4 Apr 2007 10:48:58 -0400
Eric Covener [EMAIL PROTECTED] wrote:
Can any proxy gurus reconsider this bug status?
Hmmm, I have some recollection of debating this before,
presumably without reaching any consensus for change.
-if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status)) {
+if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status) || ap_is_HTTP_REDIRECT(r-status)) {
I don't think we could accept that, because it breaks existing
behaviour someone might be relying on.
What I'd suggest is giving conf-error_override a numeric value
rather than an On/Off flag, and checking
r-status conf-error_override
That way we'll get existing behaviour with it set to 300 (so we
can alias On to that), and get the behaviour you want with 400
(which could perhaps be given another alias).
Any objections to that?
Thanks Nick -- Looks reasonable, but flipping the comparison might
make more sense based on the structure of context:
# 2.2.4 behavior
# Alias for ProxyErrorOverride 300
ProxyErrorOverride on
# Only override 4xx/5xx
# Alias as ERRORS ?
ProxyErrorOverride 400
if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status) ||
r-status = conf-error_override) {
// no override
--
Eric Covener
[EMAIL PROTECTED]
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On Apr 4, 2007, at 11:34 AM, Georg von Zezschwitz wrote: Jim Jagielski schrieb: Rüdiger's point is that we would be doing the scanning for each and every request, which is wasteful since they aren't changing. Even in the above the strlen() is counting chars that don't change between requests. the performance aspect is why I would also prefer the arbitrary sequence of stickysession-attributes with an optional Cookie/Path-prefix. Currently, the URL path search is performed before the Cookie search. I do not know why this sequence was chosen (most users will rather support cookie-based session management, so the URL approach is less likely to match). If we state that the evaluation takes place in the occurence of stickysession attributes and suggest stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to the user it will perform faster in average. As I promised to write the patch, I would do it the way Jim suggested it for backward compatibility, however I would also add a table sticky_type containing the Cookie vs. Path vs. Env-prefix (in a parsed way) to the balancer struct. Is this OK for everybody? Patch for trunk...
Re: concern about memory management
Am Montag, den 02.04.2007, 21:44 -0400 schrieb Sam Carleton: I am looking at using the deviL graphics library to downsize the images in the apache module I am developing. Currently it manages it's own memory, I don't know the details, though. Am I getting carried away with wanting to simply up and replace its current memory management system with the apache pools? Upside: No never need to care about memory ownership. Downside: If the module permanently allocs and frees again, it may become a memory hog with pools. Pools do not have realloc.So if the library reallocs a lot, the above gets even worse. Sincerely, Joachim
Re: ProxyErrorOverride and redirects (PR 39245)
On 4/4/07, Eric Covener [EMAIL PROTECTED] wrote: but flipping the comparison might make more sense based on the structure of context: Scratch that of course, -- Eric Covener [EMAIL PROTECTED]
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Mladen Turk schrieb: ... or perhaps a different notation ... stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION I like that much more - these flags like [C] rather raise questions like can I add multiple of them?. What about this?: stickysession The attribute can occur multiple times within a Balancer directive. The session identifier is searched in the sequence of the occurrence of these attributes. Each value modifier can be preceded by one of the modifiers (Cookie|Path|Env) followed by a colon, meaning that the identifier is only searched as a Cookie, an URL path element or in the environment. Without a modifier, the identifier will be searched in both the path and the cookie. (backward compatibility). The search for the identifier is case-sensitive. Regards, Georg
Re: concern about memory management
On 4/4/07, Joachim Zobel [EMAIL PROTECTED] wrote: Downside: If the module permanently allocs and frees again, it may become a memory hog with pools. but u can create subpools... so that when you free the subpool, all the memory allocated from it will be free'd, isn't it?
Re: concern about memory management
Dumindu Pallewela wrote: On 4/4/07, Joachim Zobel [EMAIL PROTECTED] wrote: Downside: If the module permanently allocs and frees again, it may become a memory hog with pools. but u can create subpools... so that when you free the subpool, all the memory allocated from it will be free'd, isn't it? this whole pool stuff should end up as ordinary malloc()s and free()s somehow, so no, i don't think that if speed is your concern, you should be using the memory management machinery of apache, because it will have its own (minimal) overhead.
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 3/23/07, David Jones [EMAIL PROTECTED] wrote: ok here's the simple patch at the 2.0.x level that just checks platforms for htdbm.c Can you post a post to htdbm.c at trunk?
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 4/4/07, Jeff Trawick [EMAIL PROTECTED] wrote: On 3/23/07, David Jones [EMAIL PROTECTED] wrote: ok here's the simple patch at the 2.0.x level that just checks platforms for htdbm.c Can you post a post to htdbm.c at trunk? whoops, make that Can you post a PATCH...
Re: concern about memory management
On Wed, 4 Apr 2007 23:49:43 +0530 Dumindu Pallewela [EMAIL PROTECTED] wrote: On 4/4/07, Joachim Zobel [EMAIL PROTECTED] wrote: Downside: If the module permanently allocs and frees again, it may become a memory hog with pools. but u can create subpools... so that when you free the subpool, all the memory allocated from it will be free'd, isn't it? Yep, but that's probably not going to be easy to make use of in a third-party library's usermem functions. Since I don't know the library you're using, I can't really offer useful advice. I could suggest the pools overview at http://www.apachetutor.org/dev/pools but I suspect you've figured most of it out already. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 04:30:31PM +0100, Nick Kew wrote:
Hmmm, I have some recollection of debating this before,
Yes, in the comments of the bug the OP linked.
presumably without reaching any consensus for change.
Well no-one's refuted (or replied to in any fashion) my last posts in
bugzilla.
-if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status)) {
+if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status) || ap_is_HTTP_REDIRECT(r-status)) {
I don't think we could accept that, because it breaks existing
behaviour someone might be relying on.
Behaviour *has already been broken* from 2.0.x to 2.2.x - I've given
evidence of this. Our work systems heavily rely on the 2.0 behaviour.
Maybe someone else would like to repeat my tests - it's possible
it's not as simple as I think. Checking the 1.3.x behaviour would be
interesting too.
Without any evidence to the contrary though, I'd really appeal for the
patch to be applied.
Whatever happens, the documentation should be clarified. But to my mind
there is no doubt that I would not expect a redirect (or Not Modified
for that matter) to be considered an error.
Cheers
--
Stuart
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, 4 Apr 2007 22:34:31 +0100 Stuart Children [EMAIL PROTECTED] wrote: Whatever happens, the documentation should be clarified. But to my mind there is no doubt that I would not expect a redirect (or Not Modified for that matter) to be considered an error. The semantics of Error here are the same as in ErrorDocument (which is, after all, what you're invoking with ProxyErrorOverride). -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: ProxyErrorOverride and redirects (PR 39245)
On 4/4/07, Nick Kew [EMAIL PROTECTED] wrote: What I'd suggest is giving conf-error_override a numeric value rather than an On/Off flag, and checking r-status conf-error_override That way we'll get existing behaviour with it set to 300 (so we can alias On to that), and get the behaviour you want with 400 (which could perhaps be given another alias). new patch available that preserves the old behavior wrt 3xx responses using the strategy quoted above -- no thought given to change in behavior of 1xx responses http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 -- Eric Covener [EMAIL PROTECTED]
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 10:40:27PM +0100, Nick Kew wrote: Whatever happens, the documentation should be clarified. But to my mind there is no doubt that I would not expect a redirect (or Not Modified for that matter) to be considered an error. The semantics of Error here are the same as in ErrorDocument (which is, after all, what you're invoking with ProxyErrorOverride). Absolutely. Only if I RTFM: http://httpd.apache.org/docs/2.2/mod/core.html#errordocument it says In the event of a problem or error. So what's wrong with what I've said? I take problem/error to not include 3xx responses. If you disagree then the documentation would appear to not be clear enough to one or other of us. Given it does not explicitly indicate behaviour in this particular matter, we should look at what the code does; which _was_ not to treat them as errors... until someone made a change at which point it broke peoples' assumptions/environments and caused them to file bugs. -- Stuart
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, 4 Apr 2007 18:08:14 -0400 Eric Covener [EMAIL PROTECTED] wrote: new patch available that preserves the old behavior wrt 3xx responses using the strategy quoted above -- no thought given to change in behavior of 1xx responses http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 Thanks. Bug me if I don't get around to reviewing/applying it. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
[STATUS] (httpd-trunk) Wed Apr 4 23:47:18 2007
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
gracefully self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
hot spare).
See: Message-ID: [EMAIL PROTECTED]
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see MUST v.s. SHOULD v.s. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
[STATUS] (httpd-2.0) Wed Apr 4 23:48:10 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-03-20 22:53:42 -0500 (Tue, 20 Mar 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.60 : in maintenance 2.0.59 : released July 28, 2006 as GA. 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: * mod_proxy: ProxyTimeout (and others) ignored due to not merging the *_set params. PR# 11540 Trunk version of patch: http://svn.apache.org/viewvc?view=revrevision=507516 2.0 version: http://people.apache.org/~jim/patches/httpd-2.0-proxy.patch +1: jim, minfrin, wrowe PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: Location bug and Cookie support
Re: translate_name and/or map_to_storage hooks
On 4/4/07, Graham Dumpleton [EMAIL PROTECTED] wrote: I missed out on the start of this conversion so really don't know what you are trying to do I have one module that does a few different things. 1: create a index html document of images 2: create a page html document of one image (when user clicks on an image in the index) 3: Handle the image request that are in the HTML of #1 and #2 and send out all the images. Right now I have it all written in PHP, there is a index.php for #1 and #2 and an imageHandler.php for #3. I am trying to understand the best way to separate this logic within my one module. Someone else suggested I look at hooking translate_name. I found my answer to how to determine the location, so I have been playing with it since my post and when I set the r-filename = images; and return OK, I get a 403 Forbidden. why aren't you just using mod_rewrite? This is going to be packaged software and I would, ideally, like to keep it all self contained so that end users that decide to start hacking things, cannot get too far.
