Re: apr_inet_pton
Cesar Silveira wrote: Hello, Not sure if this is the right place to ask this. Does anyone know why apr_inet_pton seems not to be available in the APR library's public API? By looking at the source code I have found it is only implemented on UNIX-specific files. However, I was able to take the code and simply paste and compile it on Visual Studio 2005 and it worked perfectly. I'll be really glad if anyone can provide me some input on that. APR questions are better suited to the apr-dev mailing list. What you need to do with apr_inet_pton that cannot be done with other public APR functions? Regards, -- Davi Arnaut
Re: AuthzMergeRules directive
On Wed, Apr 16, 2008 at 9:31 PM, Brad Nicholes [EMAIL PROTECTED] wrote: I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward. +1. AND makes more sense as the default - if they want OR, they can use a directive... -- justin
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a Release before the board report or else Release at board report cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the ship 1.3.0 with 2.2.9 thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires changes in both mod_rewrite and mod_proxy. I will propose a patch soon. Cheers Jean-Frederic
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht- Von: jean-frederic clere [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. April 2008 11:02 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a Release before the board report or else Release at board report cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the ship 1.3.0 with 2.2.9 thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). Regards Rüdiger
Crush (libketama improved)
Steve Yen posted this link on the memcached mailing list the other day: http://www.ssrc.ucsc.edu/Papers/weil-sc06.pdf well worth a read - and seems to take out most downsides of (lib)ketama its method. This may well be the (one) generic hasher apr/mod_*_cache needs. Thanks, Dw
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
jean-frederic clere wrote: I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires changes in both mod_rewrite and mod_proxy. I will propose a patch soon. Thank you! -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Plüm wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). That makes sense -- as we're only having issues with ; to the best of my knowledge. That said, we need to use the rewrite stuff shown in the bug (unless there's another way we're missing) to forward just the appropriate requests to Tomcat. Is there a way we're missing (that would ideally be clearly documented...) to avoid running into issues with ; when using mod_proxy and mod_rewrite as we are? If not, then one is really needed for ;. -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht- Von: Jess Holle [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. April 2008 12:36 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Plüm wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). That makes sense -- as we're only having issues with ; to the best of my knowledge. That said, we need to use the rewrite stuff shown in the bug (unless there's another way we're missing) to forward just the appropriate requests to Tomcat. Is there a way we're missing (that would ideally be clearly documented...) to avoid running into issues with ; when using mod_proxy and mod_rewrite as we are? If not, then one is really needed for ;. Have your tried something like ProxyPassMatch (^/somewhere/.*jsp$) http://backend$1 nocanon ? Regards Rüdiger
changes in cache, but not in proxy
A while ago - the build-more changes to cache where committed - but the similar changes to proxy where not. Any objections to do so ? Or is there a worry I've missed ? Dw Index: modules/proxy/config.m4 === --- modules/proxy/config.m4 (revision 649044) +++ modules/proxy/config.m4 (working copy) @@ -7,7 +7,7 @@ elif test $enable_proxy = yes; then proxy_mods_enable=yes else - proxy_mods_enable=no + proxy_mods_enable=most fi
Centralizing http-proxy knowledge in cache_util.c
Before I give the other modules a pass over -- does below strawman
address everyones
concerns w.r. to the API changes ?
To recap:
- ap_cache_cacheable_hdrs_out gets depricated. And the repliced
code is to be removed from mod_*_cache.
- a ap_cache_cacheable_hdrs_in() and ap_cache_cacheable_hdrs_out()
are added, which each rely on:
- ap_cache_cacheable_headers - which knows the HTTP rules.
The intention is to make sure that caching modules do no longer have to
understand the section in RFC 2616 deling with hop-by-hop.
Right now _out is just a wrapper for ap_cache_cacheable_headers - but
I expect that we'll have to populate it soon. And to avoid an API
version
bump I'd thus rather not do it as a #define for now.
Thanks,
Dw.
Index: CHANGES
===
--- CHANGES (revision 649044)
+++ CHANGES (working copy)
@@ -2,6 +2,14 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) cache: remove ap_cache_cacheable_hdrs_out() which was used
+ for both in- and out-put headers; and replace it by a single
+ ap_cache_cacheable_headers() wrapped in a in- and out-put
+ specific ap_cache_cacheable_hdrs_in()/out(). The latter
+ which will also merge error and ensure content-type. To keep
+ cache modules consistent with ease. This API change bumps
+ up the minor MM by one [Dirk-Willem van Gulik].
+
*) mod_rewrite: Allow Cookie option to set secure and HttpOnly
flags.
PR 44799 [Christian Wenz christian wenz.org]
Index: modules/cache/mod_cache.h
===
--- modules/cache/mod_cache.h (revision 649044)
+++ modules/cache/mod_cache.h (working copy)
@@ -286,9 +286,27 @@
const char *key, char **val);
CACHE_DECLARE(const char *)ap_cache_tokstr(apr_pool_t *p, const char
*list, const char **str);
-/* Create a new table consisting of those elements from a request_rec's
- * headers_out that are allowed to be stored in a cache
+/* Create a new table consisting of those elements from an
+ * headers table that are allowed to be stored in a cache.
*/
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t
*pool,
+apr_table_t *t,
+server_rec *s);
+
+/* Create a new table consisting of those elements from an input
+ * headers table that are allowed to be stored in a cache.
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers_in(request_rec
* r);
+
+/* Create a new table consisting of those elements from an output
+ * headers table that are allowed to be stored in a cache;
+ * ensure there is a content type and capture any errors.
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_headers_out(request_rec * r);
+
+/* Legacy call - functionally equivalent to ap_cache_cacheable_headers.
+ * @deprecated @see ap_cache_cacheable_headers
+ */
CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
apr_table_t
*t,
server_rec
*s);
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 649044)
+++ modules/cache/cache_util.c (working copy)
@@ -577,10 +577,10 @@
return apr_pstrdup(p, hashfile);
}
-/* Create a new table consisting of those elements from an input
+/* Create a new table consisting of those elements from an
* headers table that are allowed to be stored in a cache.
*/
-CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t
*pool,
apr_table_t
*t,
server_rec *s)
{
@@ -588,12 +588,20 @@
char **header;
int i;
+/* Short circuit the common case that there are not
+ * (yet) any headers populated.
+ */
+if (t == NULL) {
+ return apr_table_make(pool, 10);
+};
+
/* Make a copy of the headers, and remove from
* the copy any hop-by-hop headers, as defined in Section
* 13.5.1 of RFC 2616
*/
apr_table_t *headers_out;
headers_out = apr_table_copy(pool, t);
+
apr_table_unset(headers_out, Connection);
apr_table_unset(headers_out, Keep-Alive);
apr_table_unset(headers_out, Proxy-Authenticate);
@@ -605,6 +613,7 @@
conf = (cache_server_conf *)ap_get_module_config(s-module_config,
cache_module);
+
/* Remove the user defined headers set with CacheIgnoreHeaders.
* This may break RFC 2616 compliance on behalf of the
administrator.
*/
Re: Centralizing http-proxy knowledge in cache_util.c (resend with fix)
(Resent - previous patch also contained the module changes).
Before I give the other modules a pass over -- does below strawman
address everyones
concerns w.r. to the API changes ?
To recap:
- ap_cache_cacheable_hdrs_out gets depricated. And the repliced
code is to be removed from mod_*_cache.
- a ap_cache_cacheable_hdrs_in() and ap_cache_cacheable_hdrs_out()
are added, which each rely on:
- ap_cache_cacheable_headers - which knows the HTTP rules.
The intention is to make sure that caching modules do no longer have to
understand the section in RFC 2616 deling with hop-by-hop.
Right now _out is just a wrapper for ap_cache_cacheable_headers - but
I expect that we'll have to populate it soon. And to avoid an API
version
bump I'd thus rather not do it as a #define for now.
Thanks,
Dw.
Index: CHANGES
===
--- CHANGES (revision 649044)
+++ CHANGES (working copy)
@@ -2,6 +2,14 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) cache: remove ap_cache_cacheable_hdrs_out() which was used
+ for both in- and out-put headers; and replace it by a single
+ ap_cache_cacheable_headers() wrapped in a in- and out-put
+ specific ap_cache_cacheable_hdrs_in()/out(). The latter
+ which will also merge error and ensure content-type. To keep
+ cache modules consistent with ease. This API change bumps
+ up the minor MM by one [Dirk-Willem van Gulik].
+
*) mod_rewrite: Allow Cookie option to set secure and HttpOnly flags.
PR 44799 [Christian Wenz christian wenz.org]
Index: modules/cache/mod_cache.h
===
--- modules/cache/mod_cache.h (revision 649044)
+++ modules/cache/mod_cache.h (working copy)
@@ -286,9 +286,27 @@
const char *key, char **val);
CACHE_DECLARE(const char *)ap_cache_tokstr(apr_pool_t *p, const char
*list, const char **str);
-/* Create a new table consisting of those elements from a request_rec's
- * headers_out that are allowed to be stored in a cache
+/* Create a new table consisting of those elements from an
+ * headers table that are allowed to be stored in a cache.
*/
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t
*pool,
+apr_table_t *t,
+server_rec *s);
+
+/* Create a new table consisting of those elements from an input
+ * headers table that are allowed to be stored in a cache.
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers_in(request_rec
* r);
+
+/* Create a new table consisting of those elements from an output
+ * headers table that are allowed to be stored in a cache;
+ * ensure there is a content type and capture any errors.
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_headers_out(request_rec * r);
+
+/* Legacy call - functionally equivalent to ap_cache_cacheable_headers.
+ * @deprecated @see ap_cache_cacheable_headers
+ */
CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
apr_table_t *t,
server_rec *s);
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 649044)
+++ modules/cache/cache_util.c (working copy)
@@ -577,10 +577,10 @@
return apr_pstrdup(p, hashfile);
}
-/* Create a new table consisting of those elements from an input
+/* Create a new table consisting of those elements from an
* headers table that are allowed to be stored in a cache.
*/
-CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t
*pool,
apr_table_t *t,
server_rec *s)
{
@@ -588,12 +588,20 @@
char **header;
int i;
+/* Short circuit the common case that there are not
+ * (yet) any headers populated.
+ */
+if (t == NULL) {
+ return apr_table_make(pool, 10);
+};
+
/* Make a copy of the headers, and remove from
* the copy any hop-by-hop headers, as defined in Section
* 13.5.1 of RFC 2616
*/
apr_table_t *headers_out;
headers_out = apr_table_copy(pool, t);
+
apr_table_unset(headers_out, Connection);
apr_table_unset(headers_out, Keep-Alive);
apr_table_unset(headers_out, Proxy-Authenticate);
@@ -605,6 +613,7 @@
conf = (cache_server_conf *)ap_get_module_config(s-module_config,
cache_module);
+
/* Remove the user defined headers set with CacheIgnoreHeaders.
* This may break RFC 2616 compliance on behalf of the
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Plüm wrote: -Ursprüngliche Nachricht- Von: jean-frederic clere [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. April 2008 11:02 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a Release before the board report or else Release at board report cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the ship 1.3.0 with 2.2.9 thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r-unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. Cheers Jean-Frederic Regards Rüdiger
Re: Centralizing http-proxy knowledge in cache_util.c
-Ursprüngliche Nachricht-
Von: Dirk-Willem van Gulik
Gesendet: Donnerstag, 17. April 2008 13:05
An: dev@httpd.apache.org
Betreff: Centralizing http-proxy knowledge in cache_util.c
Before I give the other modules a pass over -- does below strawman
address everyones
concerns w.r. to the API changes ?
To recap:
- ap_cache_cacheable_hdrs_out gets depricated. And the repliced
code is to be removed from mod_*_cache.
- a ap_cache_cacheable_hdrs_in() and ap_cache_cacheable_hdrs_out()
are added, which each rely on:
- ap_cache_cacheable_headers - which knows the HTTP rules.
The intention is to make sure that caching modules do no
longer have to
understand the section in RFC 2616 deling with hop-by-hop.
Right now _out is just a wrapper for ap_cache_cacheable_headers - but
I expect that we'll have to populate it soon. And to avoid an API
version
bump I'd thus rather not do it as a #define for now.
Thanks,
Dw.
Index: modules/cache/mod_cache.h
===
--- modules/cache/mod_cache.h (revision 649044)
+++ modules/cache/mod_cache.h (working copy)
@@ -614,3 +623,44 @@
}
return headers_out;
}
+
+/* Legacy call - functionally equivalent to
ap_cache_cacheable_headers.
+ * @deprecated @see ap_cache_cacheable_headers
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_hdrs_out(apr_pool_t *p,
+
apr_table_t *t,
+
server_rec *s)
+{
+return ap_cache_cacheable_headers(p,t,s);
+}
+
+/* Create a new table consisting of those elements from an input
+ * headers table that are allowed to be stored in a cache.
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_headers_in(request_rec
* r)
+{
+ return ap_cache_cacheable_hdrs(r-pool, r-headers_in,
r-server);
+}
+
+/* Create a new table consisting of those elements from an output
+ * headers table that are allowed to be stored in a cache;
+ * ensure there is a content type and capture any errors.
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_headers_out(request_rec * r)
+{
+ apr_table_t *headers_out;
+
+ headers_out = ap_cache_cacheable_hdrs(r-pool, r-headers_out,
+ r-server);
What is this function (ap_cache_cacheable_hdrs)? I am trying to get confused
by all these functions which sound very similar :-).
+
+if (!apr_table_get(headers_out, Content-Type)
+ r-content_type) {
+apr_table_setn(headers_out, Content-Type,
+ ap_make_content_type(r, r-content_type));
+}
+
+headers_out = apr_table_overlay(r-pool, headers_out,
+r-err_headers_out);
+
+ return headers_out;
+}
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
jean-frederic clere wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r-unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. I can confirm that using ProxyPass and nocanon does not solve the problem -- I just tested this. -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht- Von: jean-frederic clere Gesendet: Donnerstag, 17. April 2008 13:39 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Plüm wrote: -Ursprüngliche Nachricht- Von: jean-frederic clere Gesendet: Donnerstag, 17. April 2008 11:02 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a Release before the board report or else Release at board report cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the ship 1.3.0 with 2.2.9 thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r-unparsed_uri. No. It does use r-unparsed_uri if r-uri and r-unparsed_uri both match the ProxyPass(Match) condition. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. We don't need to as we already call ap_proxy_canonenc on the URL which does this. Regards Rüdiger
Getting httpd to dump core on RHEL5
Hi all, I am trying to get a core dump out of an RHEL5 system, and I am struggling to do so. Following the instructions at http://httpd.apache.org/dev/debugging.html#crashes, I have set ulimit -c unlimited, and I set CoreDumpDirectory to /tmp, but with no luck. Is there some further magic that needs to be done to get httpd to dump core successfully on Linux? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Centralizing http-proxy knowledge in cache_util.c
On Apr 17, 2008, at 1:50 PM, Plüm, Rüdiger, VF-Group wrote: What is this function (ap_cache_cacheable_hdrs)? I am trying to get confused by all these functions which sound very similar :-). Basically I try to rationalize it to: 1) ap_cache_cacheable_hdrs Understands the general Hop by Hop rules - i.e. which headers are cachable and which are not - regardless of 'direction'. Could be renamed to ap_cache_cacheable_headers if we break the old naming convention a little. 2) ap_cache_cacheable_headers_out 3) ap_cache_cacheable_headers_in Understand the above -AND- the rules for outbound and inbound headers. Right now there are no extra outbound rules yet (it defers to the general i/o case). But I expect thoseto be there the moment we bring the mem-cache and memcached into the fold. And I also expect the other one to get a bit more complex when we start doing error pages proper (e.g. when there is a proxypass). Thanks, Dw.
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht- Von: Jess Holle Gesendet: Donnerstag, 17. April 2008 13:59 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) jean-frederic clere wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r-unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. I can confirm that using ProxyPass and nocanon does not solve the problem -- I just tested this. I jsut retested with trunk again (/test/foo%3Bbar?spaz=bot). In the nocanon case we sent /test/foo%253Bbar%3Fspaz=bot via AJP (network sniff) and in the case without noncanon we sent /test/foo;bar So in the first case we escape too often and in the second we do not escape enough. But the patch I just attached to PR44803 should fix this: https://issues.apache.org/bugzilla/attachment.cgi?id=21826 So ProxyPassMatch does now work as desired (with option nocanon of course). Regards Rüdiger
low hanging fruit in proxy_balancer
One of our class attendees this week had an interesting suggesting for a balancer-manager feature. Right now each member is a 2-state, either enabled or disabled. For session stickiness, he suggested a tristate third option to bleed out the remaining sessions, dispatching no /new/ sessions into the particular member. This would let the existing sessions drain and complete, in order to take down a member without disrupting any logins. Of course my plate is entirely full for several months, so I'm just tossing it out to balancer fans to see if anyone shares his itch. Bill
Re: Centralizing http-proxy knowledge in cache_util.c
-Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Donnerstag, 17. April 2008 14:19 An: dev@httpd.apache.org Betreff: Re: Centralizing http-proxy knowledge in cache_util.c On Apr 17, 2008, at 1:50 PM, Plüm, Rüdiger, VF-Group wrote: What is this function (ap_cache_cacheable_hdrs)? I am trying to get confused by all these functions which sound very similar :-). Basically I try to rationalize it to: 1)ap_cache_cacheable_hdrs Understands the general Hop by Hop rules - i.e. which headers are cachable and which are not - regardless of 'direction'. Could be renamed to ap_cache_cacheable_headers if we break the old naming convention a little. Which you already had done in your patch. Hence the confusion :-). Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote: jean-frederic clere wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r-unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. I can confirm that using ProxyPass and nocanon does not solve the problem -- I just tested this. Hmmm mod_proxy_http is aware, but methinks mod_proxy_ajp may not be at this point :/
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote:
jean-frederic clere wrote:
IMHO we already forward them escaped. The problem is that things get
unescaped first and for reserved characters like ';' this process
cannot be reverted. So if the original URL contained an escaped ';'
the forwarded one will contain a literal ';'.
With mod_proxy or better ProxyPass you already can get around this
by specifying the nocanon option which causes the the original
URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
No nocanon doesn't do that. it use url (in which the %3B is already
converted in ;) instead the r-unparsed_uri.
And that would be JK_OPT_FWDURICOMPATUNPARSED and not
ForwardURIEscaped.
To get ForwardURIEscaped we could call ap_escape_uri() on url.
I can confirm that using ProxyPass and nocanon does not solve the
problem -- I just tested this.
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c (revision 648735)
+++ modules/proxy/mod_proxy_ajp.c (working copy)
@@ -72,8 +72,13 @@
search = r-args;
/* process path */
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
- r-proxyreq);
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
+ enc_path, 0, r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
Re: low hanging fruit in proxy_balancer
-Ursprüngliche Nachricht- Von: William A. Rowe, Jr. Gesendet: Donnerstag, 17. April 2008 14:49 An: dev@httpd.apache.org Betreff: low hanging fruit in proxy_balancer One of our class attendees this week had an interesting suggesting for a balancer-manager feature. Right now each member is a 2-state, either enabled or disabled. For session stickiness, he suggested a tristate third option to bleed out the remaining sessions, dispatching no /new/ sessions into the particular member. This would let the existing sessions drain and complete, in order to take down a member without disrupting any logins. In principle we already have this, but we do not make any difference between PROXY_WORKER_DISABLED and PROXY_WORKER_STOPPED and of course we are are missing the needed field in the balancer manager of course to switch between enabled, disabled and stopped. Regards Rüdiger
Re: low hanging fruit in proxy_balancer
On Apr 17, 2008, at 8:49 AM, William A. Rowe, Jr. wrote: One of our class attendees this week had an interesting suggesting for a balancer-manager feature. Right now each member is a 2-state, either enabled or disabled. For session stickiness, he suggested a tristate third option to bleed out the remaining sessions, dispatching no /new/ sessions into the particular member. This would let the existing sessions drain and complete, in order to take down a member without disrupting any logins. Of course my plate is entirely full for several months, so I'm just tossing it out to balancer fans to see if anyone shares his itch. This isn't the 1st time this has been suggested... Having a 'On/Off/Taking-offline' state engine.
Re: Analyze mod_rewrite log in browser
On Apr 16, 2008, at 9:57 PM, Christoph Dorn wrote:
I was wondering if it would be useful for a lot of mod_rewrite users
to
be able to view the rewrite log in their Firebug console instead of
...
There could be a new configuration directive for mod_rewrite that
enables the sending of the rewrite log for specific IP's for instance.
This would also be useful in that rewrite logging would not need to be
turned on for all users.
...
Is this something that would be useful to have for mod_rewrite users?
...
Could this be added to the default mod_rewrite module? A separate
module?
Couple of issues/thoughts here
- We right now have the '/file..' and '|to a pipe' construct
in use for logging in quite a few places. One could
add an extra ':json-header' or similar 'alert'.
- But we do not readily allow multiple outputs (depending on
how it is configured, quite confusing - your next Log directive
will overwrite or be in parallel with a previous/higher one).
So rationalizing this and adding an extra option would be goodness.
However:
- Right now -most- logging is done at the very end - and the firebug
method assumes that it is all ready when/prior to the header
going out. Not sure how to solve this. Though with Chunked and
multipart replies you can perhaps post-append the header in a way
acceptable to both firebug and the http guru's.
- While there is an ap_log_write sort of thing in mod_log_config
and the other loggers/* are fairly sane - mod_rewrite
does its own open_rewritelog(). So that would have to be
sanitized as well. But that would be goodness.
However this makes it a fairly big project.
Could this be added to the default mod_rewrite module? A separate
module?
In the current setup you'd have to add it into mod_rewrite; and it
would just work
for mod_rewrite. I'd directly attack do_rewritelog() by putting a line
in which
adds to the header (see outline below which is adapted from a similar
feature
for the oracle IDE). Dirty like hell.
Dw.
Index: mod_rewrite.c
===
--- mod_rewrite.c (revision 648690)
+++ mod_rewrite.c (working copy)
@@ -294,6 +294,7 @@
apr_array_header_t *rewriteconds; /* the RewriteCond entries
(temp.)*/
apr_array_header_t *rewriterules; /* the RewriteRule
entries*/
server_rec *server; /* the corresponding server
indicator */
+int firebug;
} rewrite_server_conf;
typedef struct {
@@ -537,6 +538,20 @@
/* XXX: Maybe this should be fatal? */
}
+/* Add current logline to a (to be created firebug line) */
+if (conf-firebug) {
+ char * p = apr_table_get(r-headers_out,X-FirePHP-Data);
+#define FB_PREFIX ({ \FirePHP.Firebug.Console\:[ )
+#define FB_POSTFIX (]})
+ if (p) {
+ p = p + sizeof(FB_PREFIX);
+ p[ strlen(p) - sizeof(FB_POSTFIX) ] = '\0';
+ }
+ p = apr_pstrcat(r-pool, FB_PREFIX, [\LOG\,[\rewrite\,\,
logline, \]]
+p ? , : , p ? p : , FB_POSTFIX, NULL);
+apr_table_setn(r-headers_out, X-FirePHP-Data, p);
+};
return;
}
#endif /* !REWRITELOG_DISABLED */
@@ -2726,6 +2741,7 @@
a-rewritelogfile = NULL;
a-rewritelogfp= NULL;
a-rewriteloglevel = 0;
+a-firebug = 0;
#endif
a-rewritemaps = apr_hash_make(p);
a-rewriteconds= apr_array_make(p, 2,
sizeof(rewritecond_entry));
@@ -4963,6 +4979,8 @@
AP_INIT_TAKE1( RewriteLogLevel, cmd_rewriteloglevel, NULL,
RSRC_CONF,
the level of the rewriting logfile verbosity
(0=none, 1=std, .., 9=max)),
+AP_INIT_FLAG( RewriteLogFirebug, cmd_firebugenable, NULL,
RSRC_CONF,
+ Enable or disable firebug support),
#else
AP_INIT_TAKE1( RewriteLog, fake_rewritelog, NULL, RSRC_CONF,
[DISABLED] the filename of the rewriting
logfile),
Re: low hanging fruit in proxy_balancer
On Apr 17, 2008, at 8:56 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: William A. Rowe, Jr. Gesendet: Donnerstag, 17. April 2008 14:49 An: dev@httpd.apache.org Betreff: low hanging fruit in proxy_balancer One of our class attendees this week had an interesting suggesting for a balancer-manager feature. Right now each member is a 2-state, either enabled or disabled. For session stickiness, he suggested a tristate third option to bleed out the remaining sessions, dispatching no /new/ sessions into the particular member. This would let the existing sessions drain and complete, in order to take down a member without disrupting any logins. In principle we already have this, but we do not make any difference between PROXY_WORKER_DISABLED and PROXY_WORKER_STOPPED and of course we are are missing the needed field in the balancer manager of course to switch between enabled, disabled and stopped. Yeah, but we *should* differentiate between the 2. There are (well, should be) administrative status and runtime status.
Re: perform a redirect in output filter
John Zhang wrote:
I am using apache 2.0/2.2, in my output filter, I
would like to have the ability to redirect. Some
tests indicated that I can redirect to a page on the
same site, but not to an external site.
Here is my code for redirect:
char* location =
apr_table_get(r-headers_out, Location);
//Note this Location is set by my filter during the
process, so I know I need to do a redirect.
if(location location[0])
{
//r-status = 301;
r-method = apr_pstrdup(r-pool, GET);
r-method_number = M_GET;
apr_table_unset(r-headers_in, Content-Length);
ap_remove_output_filter(my_filter);
ap_internal_redirect_handler(location, r);
return APR_SUCCESS;
}
//tests: (if my site is http://localhost/foo)
and when http://localhost/foo/bar.html (my test
page)is loaded I want to redirect it to
a) /foo/foo2/existing.html (works)
b) http://localhost/foo/foo2/existing.html (works)
c) http://www.google.com (does not work), instead I
get http://localhost/foo displayed on the browser.
Is there anything I did is incorrect? I noticed the
method is called *internal_redirect*, but did not
know another one for external redirect.
An internal redirect should only work with internal redirects, and I do
not know of an external.
I expect that you will have to set the f-r-status to 302, and maybe
return a small page saying that the doc moved. Have you uncommented the
r-status line and commented out the internal_redirect line? How did
that work? (Note: an output filter, probably shouldn't be calling a
handler. You may want to destroy the bucket brigade, and then create a
new bucket brigade with the error message.)
Joe
--
Joseph Lewis http://sharktooth.org/
Re: Centralizing http-proxy knowledge in cache_util.c
On Apr 17, 2008, at 2:49 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Donnerstag, 17. April 2008 14:19 An: dev@httpd.apache.org Betreff: Re: Centralizing http-proxy knowledge in cache_util.c On Apr 17, 2008, at 1:50 PM, Plüm, Rüdiger, VF-Group wrote: What is this function (ap_cache_cacheable_hdrs)? I am trying to get confused by all these functions which sound very similar :-). Basically I try to rationalize it to: 1) ap_cache_cacheable_hdrs Understands the general Hop by Hop rules - i.e. which headers are cachable and which are not - regardless of 'direction'. Could be renamed to ap_cache_cacheable_headers if we break the old naming convention a little. Which you already had done in your patch. Hence the confusion :-). Ah Apologies - that _is_ confusing :) Dw.
Re: low hanging fruit in proxy_balancer
Jim Jagielski wrote: On Apr 17, 2008, at 8:56 AM, Plüm, Rüdiger, VF-Group wrote: Yeah, but we *should* differentiate between the 2. There are (well, should be) administrative status and runtime status. It worked initially, but someone added PROXY_WORKER_STOPPED to PROXY_WORKER_IS_USABLE, which should be fine, but ONLY if there is no session route in the request (eg. new request) Regards -- (TM)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: But the patch I just attached to PR44803 should fix this: https://issues.apache.org/bugzilla/attachment.cgi?id=21826 :) Obviously, +1 on the mod_proxy_ajp patch (within minutes we had the same idea). Mulling over the impacts of the up_uri_wout_query part though...
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Donnerstag, 17. April 2008 15:16 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: But the patch I just attached to PR44803 should fix this: https://issues.apache.org/bugzilla/attachment.cgi?id=21826 :) Obviously, +1 on the mod_proxy_ajp patch (within minutes we had the same idea). Mulling over the impacts of the Yep :-) up_uri_wout_query part though... The query string was present twice (one from unparsed_uri which still contains the query string and one that was added via r-query later when running the canon_handler hook). But sure this could be also fixed in the appropriate canon_handler hooks of mod_proxy_http and mod_proxy_ajp. Regards Rüdiger
Re: Getting httpd to dump core on RHEL5
On Thu, 17 Apr 2008, Graham Leggett wrote:
Hi all,
I am trying to get a core dump out of an RHEL5 system, and I am struggling to
do so.
Following the instructions at
http://httpd.apache.org/dev/debugging.html#crashes, I have set ulimit -c
unlimited, and I set CoreDumpDirectory to /tmp, but with no luck.
Is there some further magic that needs to be done to get httpd to dump core
successfully on Linux?
On our Ubuntu boxen having ulimit -c unlimited in the httpd startup
script and CoreDumpDirectory /tmp in httpd.conf is sufficient.
kill -SEGV some-httpd-pid should yield a coredump IIRC.
The coredump will be useless unless you have compiled with -g though,
but I guess you already knew that ;)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
Stationary mice have bigger balls. (c)1991
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote: But sure this could be also fixed in the appropriate canon_handler hooks of mod_proxy_http and mod_proxy_ajp. That's what I'm wondering... Treating this special inside of mod_proxy itself, when it's really a protocol issue (and what is right for that protocol) just seems a safer way. Or, at least, helps to maintain that illusion of abstraction :)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r-args;
/* process path */
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
- r-proxyreq);
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
+ enc_path, 0, r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up to
do so), but our engineer who does is slated to test the patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jess Holle wrote:
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r-args;
/* process path */
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
- r-proxyreq);
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
+ enc_path, 0, r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up to
do so), but our engineer who does is slated to test the patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
To be more clear exactly which patch should we be testing?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
-Ursprüngliche Nachricht-
Von: Jess Holle
Gesendet: Donnerstag, 17. April 2008 16:50
An: dev@httpd.apache.org
Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jess Holle wrote:
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r-args;
/* process path */
-path = ap_proxy_canonenc(r-pool, url, strlen(url),
enc_path, 0,
- r-proxyreq);
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
+ enc_path, 0, r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have
things set up to
do so), but our engineer who does is slated to test the
patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
To be more clear exactly which patch should we be testing?
You better go with the one from the bug report. Otherwise you end up with
doubled query strings.
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:48 AM, Jess Holle wrote:
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r-args;
/* process path */
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
- r-proxyreq);
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
+ enc_path, 0, r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up
to do so), but our engineer who does is slated to test the patch
attached to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
This section is the same as that in the bug report (make mod_proxy_ajp
aware of the nocanon EnvVar), but the attached patch also includes
a workaround for the doubling of any query strings. This 2nd part
needs to be addressed but the real fix may not be done by
this patch. If you have no query args, then either is fine.
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote: This section is the same as that in the bug report (make mod_proxy_ajp aware of the nocanon EnvVar), but the attached patch also includes a workaround for the doubling of any query strings. This 2nd part needs to be addressed but the real fix may not be done by this patch. If you have no query args, then either is fine. We generally have query strings (and have to support the most general case due to the number of quite disparate pages being served), so we'll need the full patch. Thanks. -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:25 AM, Jim Jagielski wrote:
On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote:
But sure this could be also fixed in the appropriate canon_handler
hooks of mod_proxy_http and mod_proxy_ajp.
That's what I'm wondering... Treating this special inside
of mod_proxy itself, when it's really a protocol issue (and
what is right for that protocol) just seems a safer way.
Or, at least, helps to maintain that illusion of abstraction :)
Something like:
Index: mod_proxy_http.c
===
--- mod_proxy_http.c(revision 649076)
+++ mod_proxy_http.c(working copy)
@@ -72,7 +72,9 @@
* has already been decoded. True proxy requests have r-uri
* == r-unparsed_uri, and no others have that property.
*/
-if (r-uri == r-unparsed_uri) {
+if ((r-uri == r-unparsed_uri) ||
+((r-proxyreq == PROXYREQ_REVERSE)
+ apr_table_get(r-notes, proxy-nocanon))) {
search = strchr(url, '?');
if (search != NULL)
*(search++) = '\0';
ajp and fcgi similarly... :)
caching - mergeclear errors prior to hop by hop removal ?
I *think* that the patch below is the right thing to do throughout
(rather than
just in mod_cache itself):
- always merge in any error headers *prior* to removing
hop-by-hop.
- always clearing the errors.
When you are passing out a cached header set. But would love to have
people their feedback. As I cannot see any real difference in my
testcases, nor think of a good one.
Dw.
Index: cache_util.c
===
--- cache_util.c(revision 649162)
+++ cache_util.c(working copy)
@@ -650,6 +650,10 @@
{
apr_table_t *headers_out;
+headers_out = apr_table_overlay(r-pool, headers_out,
+r-err_headers_out);
+apr_table_clear(r-err_headers_out);
+
headers_out = ap_cache_cacheable_headers(r-pool, r-headers_out,
r-server);
@@ -659,8 +663,5 @@
ap_make_content_type(r, r-content_type));
}
-headers_out = apr_table_overlay(r-pool, headers_out,
-r-err_headers_out);
-
return headers_out;
}
Index: mod_cache.c
===
--- mod_cache.c (revision 649179)
+++ mod_cache.c (working copy)
@@ -757,16 +757,8 @@
* err_headers_out and we also need to strip any hop-by-hop
* headers that might have snuck in.
*/
-r-headers_out = apr_table_overlay(r-pool, r-headers_out,
- r-err_headers_out);
+r-headers_out = ap_cache_cacheable_headers_out(r);
- /* XXX check -- we're not patching up content-type - i.e. this
- * propably should be ap_cache_cacheable_headers_out().
- */
-r-headers_out = ap_cache_cacheable_headers(r-pool, r-
headers_out,
- r-server);
-apr_table_clear(r-err_headers_out);
-
/* Merge in our cached headers. However, keep any updated
values. */
ap_cache_accept_headers(cache-handle, r, 1);
}
trunk build broken...
Hmmm httpd-trunk, apr-trunk and apr-util-trunk up to date, and yet: mod_session_crypto.c:20:66: error: apr_ssl.h: No such file or directory mod_session_crypto.c:60: error: syntax error before 'apr_evp_factory_t' mod_session_crypto.c:61: warning: function declaration isn't a prototype mod_session_crypto.c: In function 'crypt_init': mod_session_crypto.c:64: error: 'conf' undeclared (first use in this function) mod_session_crypto.c:64: error: (Each undeclared identifier is reported only once mod_session_crypto.c:64: error: for each function it appears in.) mod_session_crypto.c:65: error: 'r' undeclared (first use in this function) mod_session_crypto.c:73: error: 'key' undeclared (first use in this function) mod_session_crypto.c:73: error: 'APR_EVP_KEY_PUBLIC' undeclared (first use in this function) did a full distclean beforehand...
Re: svn commit: r649170 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
On 04/17/2008 06:24 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Apr 17 09:24:16 2008
New Revision: 649170
URL: http://svn.apache.org/viewvc?rev=649170view=rev
Log:
and make mod_proxy_fcgi also nocanon aware
Modified:
httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?rev=649170r1=649169r2=649170view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Thu Apr 17 09:24:16 2008
@@ -103,8 +103,13 @@
host = apr_pstrcat(r-pool, [, host, ], NULL);
}
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
Is this correct? If it is the raw URL, url still contains the query args. This
is not the case in the else branch. So we end up with different things
regarding the query
args. I am not sure how fcgi transfers the query args to the CGI. So I do not
know what
is the correct thing in this case.
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
Regards
Rüdiger
Re: svn commit: r649170 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
These just make noncanon available for knowledge use... How
that is actually handled is additional stuff (see other thread :) )
On Apr 17, 2008, at 3:04 PM, Ruediger Pluem wrote:
On 04/17/2008 06:24 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Apr 17 09:24:16 2008
New Revision: 649170
URL: http://svn.apache.org/viewvc?rev=649170view=rev
Log:
and make mod_proxy_fcgi also nocanon aware
Modified:
httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?rev=649170r1=649169r2=649170view=diff
=
=
=
=
=
=
=
=
=
=
--- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Thu Apr 17
09:24:16 2008
@@ -103,8 +103,13 @@
host = apr_pstrcat(r-pool, [, host, ], NULL);
}
-path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
+if (apr_table_get(r-notes, proxy-nocanon)) {
+path = url; /* this is the raw path */
Is this correct? If it is the raw URL, url still contains the query
args. This
is not the case in the else branch. So we end up with different
things regarding the query
args. I am not sure how fcgi transfers the query args to the CGI. So
I do not know what
is the correct thing in this case.
+}
+else {
+path = ap_proxy_canonenc(r-pool, url, strlen(url),
enc_path, 0,
r-proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
Regards
Rüdiger
Re: caching - mergeclear errors prior to hop by hop removal ?
On 04/17/2008 06:48 PM, Dirk-Willem van Gulik wrote: I *think* that the patch below is the right thing to do throughout (rather than just in mod_cache itself): -always merge in any error headers *prior* to removing hop-by-hop. -always clearing the errors. When you are passing out a cached header set. But would love to have people their feedback. As I cannot see any real difference in my testcases, nor think of a good one. Seems to make sense from the first glance. Regards Rüdiger
Re: svn commit: r649239 - in /httpd/httpd/trunk/modules/proxy: mod_proxy_ajp.c mod_proxy_http.c
On Thu, 17 Apr 2008 [EMAIL PROTECTED] wrote: Log: handle ? in cases where nocanon is in effect Lovely - this fixes one of my ajp problems as well (which I thus wrongly was blaming on the cache). Is this now hooked in everywhere ? Or do we still need to do a scan throughout everything ? Dw
Re: svn commit: r649228 - in /httpd/httpd/trunk/modules/cache: cache_util.c mod_cache.c
On Thu, 17 Apr 2008 [EMAIL PROTECTED] wrote: * Style police. No functional changes. Are you using .indent.pro ? If so - which one ? Thanks, Dw
Re: svn commit: r649239 - in /httpd/httpd/trunk/modules/proxy: mod_proxy_ajp.c mod_proxy_http.c
On 04/17/2008 09:20 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Apr 17 12:20:16 2008
New Revision: 649239
URL: http://svn.apache.org/viewvc?rev=649239view=rev
Log:
handle ? in cases where nocanon is in effect
Modified:
httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c
httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?rev=649239r1=649238r2=649239view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c Thu Apr 17 12:20:16 2008
@@ -31,6 +31,7 @@
{
char *host, *path, *search, sport[7];
const char *err;
+const char *pnocanon;
apr_port_t port = AJP13_DEF_PORT;
/* ap_port_of_scheme() */
@@ -63,7 +64,8 @@
* has already been decoded. True proxy requests have
* r-uri == r-unparsed_uri, and no others have that property.
*/
-if (r-uri == r-unparsed_uri) {
+pnocanon = apr_table_get(r-notes, proxy-nocanon);
+if ((r-uri == r-unparsed_uri) || pnocanon) {
search = strchr(url, '?');
if (search != NULL)
*(search++) = '\0';
@@ -72,7 +74,7 @@
search = r-args;
/* process path */
-if (apr_table_get(r-notes, proxy-nocanon)) {
+if (pnocanon) {
path = url; /* this is the raw path */
}
else {
I am frankly open here: The old code already looked ugly in respect of this and
the new code IMHO even looks uglier. What about the following patch which is
IMHO much
cleaner:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c (Revision 649232)
+++ modules/proxy/mod_proxy_ajp.c (Arbeitskopie)
@@ -58,18 +58,8 @@
/*
* now parse path/search args, according to rfc1738
- *
- * N.B. if this isn't a true proxy request, then the URL _path_
- * has already been decoded. True proxy requests have
- * r-uri == r-unparsed_uri, and no others have that property.
*/
-if (r-uri == r-unparsed_uri) {
-search = strchr(url, '?');
-if (search != NULL)
-*(search++) = '\0';
-}
-else
-search = r-args;
+search = NULL;
/* process path */
if (apr_table_get(r-notes, proxy-nocanon)) {
@@ -78,6 +68,7 @@
else {
path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path, 0,
r-proxyreq);
+search = r-args;
}
if (path == NULL)
return HTTP_BAD_REQUEST;
Re: svn commit: r649228 - in /httpd/httpd/trunk/modules/cache: cache_util.c mod_cache.c
On 04/17/2008 09:39 PM, Dirk-Willem van Gulik wrote: On Thu, 17 Apr 2008 [EMAIL PROTECTED] wrote: * Style police. No functional changes. Are you using .indent.pro ? If so - which one ? No, I am using the following .vimrc settings which I took over from Justin: syntax enable Added entries from Justins vimrc file Makefiles ALWAYS must have real TABS autocmd FileType make set noet let c_syntax_for_h=1 autocmd FileType c set ts=4 sw=4 et cindent cino=:0(0 fo+=ro Denote tabs with a double chevron and trailing spaces with a funny char set list listchars=tab:»·,trail:· set showmatch Regards Rüdiger
Re: trunk build broken...
Trunk should now build again. Regards Rüdiger On 04/17/2008 07:25 PM, Jim Jagielski wrote: Hmmm httpd-trunk, apr-trunk and apr-util-trunk up to date, and yet: mod_session_crypto.c:20:66: error: apr_ssl.h: No such file or directory mod_session_crypto.c:60: error: syntax error before 'apr_evp_factory_t' mod_session_crypto.c:61: warning: function declaration isn't a prototype mod_session_crypto.c: In function 'crypt_init': mod_session_crypto.c:64: error: 'conf' undeclared (first use in this function) mod_session_crypto.c:64: error: (Each undeclared identifier is reported only once mod_session_crypto.c:64: error: for each function it appears in.) mod_session_crypto.c:65: error: 'r' undeclared (first use in this function) mod_session_crypto.c:73: error: 'key' undeclared (first use in this function) mod_session_crypto.c:73: error: 'APR_EVP_KEY_PUBLIC' undeclared (first use in this function) did a full distclean beforehand...
Re: svn commit: r649239 - in /httpd/httpd/trunk/modules/proxy: mod_proxy_ajp.c mod_proxy_http.c
On 04/17/2008 10:10 PM, Ruediger Pluem wrote: I am frankly open here: The old code already looked ugly in respect of this and the new code IMHO even looks uglier. What about the following patch Of course I forgot a :-) here. Regards Rüdiger
patch for flood to deal with gcc 4
Folks
Here's the patch to get this to compile correctly with gcc 4. It's
actually only 3 lines. This has been tested with the following
versions:
gcc version 3.4.6 20060404 (Red Hat 3.4.6-8), (RHEL4 32-bit)
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52) (RHEL4 64-bit)
Thanks,
Guy
--
Guy Ferraiolo mailto:[EMAIL PROTECTED]
Performance Measurement Analysis http://CNET.com
CNETtel: 1.908.541.3739
1200 Route 22 East fax: 1.908.575.7474
Bridgewater, NJ 08807 cel: 1.732.618.0250
diff -urN flood/flood_round_robin.c flood-asf-patchbuild/flood_round_robin.c
--- flood/flood_round_robin.c 2008-04-15 15:07:15.317181000 -0700
+++ flood-asf-patchbuild/flood_round_robin.c 2008-04-15 15:18:04.262536000 -0700
@@ -905,7 +905,7 @@
XML_SUBST_VAR, FLOOD_STRLEN_MAX) == 0) {
if (subst_entry_child-first_cdata.first
subst_entry_child-first_cdata.first-text) {
-(subst_rec_t*)subst_rec_p-subst_var =
+subst_rec_p-subst_var =
apr_pstrdup(pool,
subst_entry_child-first_cdata.first-text);
}
@@ -915,7 +915,7 @@
XML_SUBST_FILE, FLOOD_STRLEN_MAX) == 0) {
if (subst_entry_child-first_cdata.first
subst_entry_child-first_cdata.first-text) {
-(subst_rec_t*)subst_rec_p-subst_file_name =
+subst_rec_p-subst_file_name =
apr_pstrdup(pool,
subst_entry_child-first_cdata.first-text);
}
diff -urN flood/flood_subst_file.c flood-asf-patchbuild/flood_subst_file.c
--- flood/flood_subst_file.c 2008-04-15 15:07:15.330182000 -0700
+++ flood-asf-patchbuild/flood_subst_file.c 2008-04-15 15:18:04.308533000 -0700
@@ -1,4 +1,5 @@
#include assert.h
+#include stdlib.h
#include apr_general.h
#include apr_file_io.h
#include flood_subst_file.h
Re: Solaris sed based apache filtering module (mod_sed)
On Sat, Apr 12, 2008 at 10:27:40AM -0700, Chris Elving wrote:
sed is an inherently line-oriented editor. It seems wrong to buffer
multiple lines within libsed. Consider, for example, how adding such
multi-line buffering to libsed would complicate implementing an
interactive sed like sed(1).
Instead, it seems like such buffering should occur in mod_sed. mod_sed
is what couples libsed to the bucket brigade, and mod_sed knows that
such such buffering is appropriate.
As suggested by Chris Elving, I moved the buffering code from sed code to
mod_sed filter code.
Diff from first version is attached.
New sources can be viewed at :
http://src.opensolaris.org/source/xref/webstack/mod_sed/
(as well as by mercurial : hg clone ssh://[EMAIL PROTECTED]/hg/webstack/mod_sed
)
Regards,
Basant.
Index: mod_sed.c
===
--- mod_sed.c 4 Apr 2008 02:33:57 - 1.20.2.6
+++ mod_sed.c 17 Apr 2008 21:33:01 - 1.20.2.8
@@ -26,6 +26,7 @@
#include libsed.h
static const char *sed_filter_name = Sed;
+#define MODSED_OUTBUF_SIZE 4000
typedef struct sed_expr_config
{
@@ -45,6 +46,9 @@
sed_eval_t eval;
request_rec *r;
apr_bucket_brigade *bb;
+char *outbuf;
+char *curoutbuf;
+int bufsize;
} sed_filter_ctxt;
module AP_MODULE_DECLARE_DATA sed_module;
@@ -67,10 +71,32 @@
sed_cfg-last_error = error;
}
+/*
+ * flush_output_buffer
+ * Flush the output data (stored in ctx-outbuf)
+ */
+static void flush_output_buffer(sed_filter_ctxt *ctx, char* buf, int sz)
+{
+int size = ctx-curoutbuf - ctx-outbuf;
+char *out;
+if (size + sz = 0)
+return;
+out = apr_palloc(ctx-r-pool, size + sz);
+if (size) {
+memcpy(out, ctx-outbuf, size);
+}
+if (buf (sz 0)) {
+memcpy(out + size, buf, sz);
+}
+/* Reset the output buffer position */
+ctx-curoutbuf = ctx-outbuf;
+apr_bucket *b = apr_bucket_pool_create(out, size + sz, ctx-r-pool,
+ ctx-r-connection-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(ctx-bb, b);
+}
+
/* This is a call back function. When libsed wants to generate the output,
- * this function will be invoked. Caller creates a copy of the buffer from the
- * request pool so we don't need to create a copy here. In this method, we
- * simply create a bucket and append into the brigade at the tail.
+ * this function will be invoked.
*/
static void sed_write_output(void *dummy, char *buf, int sz)
{
@@ -78,9 +104,14 @@
* of sed_eval_buffer
*/
sed_filter_ctxt *ctx = (sed_filter_ctxt *) dummy;
-apr_bucket *b = apr_bucket_pool_create(buf, sz, ctx-r-pool,
- ctx-r-connection-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(ctx-bb, b);
+if (((ctx-curoutbuf - ctx-outbuf) + sz) = ctx-bufsize) {
+/* flush current buffer */
+flush_output_buffer(ctx, buf, sz);
+}
+else {
+memcpy(ctx-curoutbuf, buf, sz);
+ctx-curoutbuf += sz;
+}
}
/* Compile a sed expression. Compiled context is saved in sed_cfg-sed_cmds.
@@ -119,6 +150,34 @@
return APR_SUCCESS;
}
+/* Initialize sed filter context. If successful then context is set in f-ctx
+ */
+static apr_status_t init_context(ap_filter_t *f, sed_expr_config *sed_cfg)
+{
+apr_status_t status;
+sed_filter_ctxt* ctx;
+request_rec *r = f-r;
+/* Create the context. Call sed_init_eval. libsed will generated
+ * output by calling sed_write_output and generates any error by
+ * invoking log_sed_errf.
+ */
+ctx = apr_pcalloc(r-pool, sizeof(sed_filter_ctxt));
+ctx-r = r;
+ctx-bb = NULL;
+status = sed_init_eval(ctx-eval, sed_cfg-sed_cmds, log_sed_errf,
+ r, sed_write_output, r-pool);
+if (status != APR_SUCCESS) {
+return status;
+}
+apr_pool_cleanup_register(r-pool, ctx-eval, sed_eval_cleanup,
+ apr_pool_cleanup_null);
+ctx-bufsize = MODSED_OUTBUF_SIZE;
+ctx-outbuf = apr_palloc(r-pool, ctx-bufsize + 1);
+ctx-curoutbuf = ctx-outbuf;
+f-ctx = ctx;
+return APR_SUCCESS;
+}
+
/* Entry function for Sed output filter */
static apr_status_t sed_response_filter(ap_filter_t *f,
apr_bucket_brigade *bb)
@@ -144,21 +203,10 @@
return ap_pass_brigade(f-next, bb);
}
-/* Create the context. Call sed_init_eval. libsed will generated
- * output by calling sed_write_output and generates any error by
- * invoking log_sed_errf.
- */
-ctx = f-ctx = apr_pcalloc(f-r-pool, sizeof(sed_filter_ctxt));
-ctx-r = f-r;
-ctx-bb = NULL;
-
-status = sed_init_eval(ctx-eval, sed_cfg-sed_cmds, log_sed_errf,
- f-r, sed_write_output, f-r-pool);
-if (status != APR_SUCCESS) {
-return status;
-}
-
