RE: Prepare for large proxy commit...
> -Original Message- > From: Jim Jagielski > Sent: Mittwoch, 12. Januar 2011 21:30 > To: dev@httpd.apache.org > Subject: Prepare for large proxy commit... > > My current migration of mod_proxy away from the scoreboard > and to slotmem is done. All that remains is some final > testing. > > This will serve as the basis for adding in members during > runtime. Currently, the idea is that we only change the > number of workers, but nothing really prevents us from > also doing it with balancers themselves at some point. > > I'll be committing most likely tomorrow... > Test suite passes with 1 regression for worker mpm: Failed TestStat Wstat Total Fail Failed List of Failed --- t/apache/mmn.t21 50.00% 2 5 tests and 18 subtests skipped. But this is just a common oversight of adding a bump comment, but not really doing the bump :-). Regards Rüdiger
Re: Prepare for large proxy commit...
Thx for the catch! Fixed. On Jan 14, 2011, at 3:56 AM, Plüm, Rüdiger, VF-Group wrote: > > >> -Original Message- >> From: Jim Jagielski >> Sent: Mittwoch, 12. Januar 2011 21:30 >> To: dev@httpd.apache.org >> Subject: Prepare for large proxy commit... >> >> My current migration of mod_proxy away from the scoreboard >> and to slotmem is done. All that remains is some final >> testing. >> >> This will serve as the basis for adding in members during >> runtime. Currently, the idea is that we only change the >> number of workers, but nothing really prevents us from >> also doing it with balancers themselves at some point. >> >> I'll be committing most likely tomorrow... >> > > Test suite passes with 1 regression for worker mpm: > > Failed TestStat Wstat Total Fail Failed List of Failed > --- > t/apache/mmn.t21 50.00% 2 > 5 tests and 18 subtests skipped. > > But this is just a common oversight of adding a bump comment, but > not really doing the bump :-). > > Regards > > Rüdiger >
Re: svn commit: r1051468 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_io.c
On Thu, Jan 13, 2011 at 03:25:22PM +0100, "Plüm, Rüdiger, VF-Group" wrote:
> Should I commit the patch below now to resolve the issue and address
> your point?
Once again we are struggling with the ill-defined filtering API :(
You're proposing here to make the _GETLINE call return a partial read in
a case where no LF is found. I think most existing callers would
probably cope fine with that, but the wording in util_filter.h is
explicit:
* (If a potential line is too long or no CRLF is found, the
* filter may return partial data).
i.e. it does not make mention of non-blocking mode.
So I think it would be best to revert the second half of the patch and
leave the first half as-is, i.e. patch as below - if this makes sense to
you also?
I've been trying to make a test case which tickles this issue but have
so far not managed to get a non-blocking GETLINE call with the filter in
the right state.
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 1054976)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -786,10 +786,6 @@
*len = bytes;
}
-else {
-/* Safe the part of the line we already got */
-char_buffer_write(&inctx->cbuf, buf, *len);
-}
return APR_SUCCESS;
}
git and httpd
For anyone trying out git with the httpd SVN repo, or any other git-svn user, the lack of 'git svn diff' is a pain. This helps. Cheers! git-svn-diff Description: Binary data
RE: svn commit: r1051468 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_io.c
> -Original Message- > From: Joe Orton > Sent: Freitag, 14. Januar 2011 15:42 > To: dev@httpd.apache.org > Subject: Re: svn commit: r1051468 - in /httpd/httpd/trunk: > CHANGES modules/ssl/ssl_engine_io.c > > On Thu, Jan 13, 2011 at 03:25:22PM +0100, "Plüm, Rüdiger, > VF-Group" wrote: > > Should I commit the patch below now to resolve the issue and address > > your point? > > Once again we are struggling with the ill-defined filtering API :( > > You're proposing here to make the _GETLINE call return a > partial read in > a case where no LF is found. I think most existing callers would > probably cope fine with that, but the wording in util_filter.h is > explicit: > > * (If a potential line is too long or no CRLF is found, > the > * filter may return partial data). > > > i.e. it does not make mention of non-blocking mode. > > So I think it would be best to revert the second half of the > patch and > leave the first half as-is, i.e. patch as below - if this > makes sense to > you also? Makes sense. Committed as r1059037. > > I've been trying to make a test case which tickles this issue > but have > so far not managed to get a non-blocking GETLINE call with > the filter in > the right state. Have a look at the test case provided in the PR50481. This might be helpful. Regards Rüdiger
Re: Why AllowEncodedSlashes config not merged?
Bumping this one, what do you think about: a) drop "Allowing encoded slashes does not imply decoding. Occurrences of %2F or %5C (only on according systems) will be left as such in the otherwise decoded URL string." since it has been decoding them for many years b) add a new option to AllowEncodedSlashes to get the "original" behavior of not decoding or further escaping the % c) put a smartly worded security stmt about why letting these float around escaped, or unescaped, is a bad idea. For example, if the path segments won't be used to map to a file (PATH_INFO or interpreted otherwise by a script or backend) are you off the hook? d) See what exactly happens when you use this stuff with plugins like proxy, rewrite, etc. On Tue, Nov 2, 2010 at 2:03 PM, Eric Covener wrote: > On Tue, Nov 2, 2010 at 12:55 PM, Dan Poirier wrote: >> Actually, from https://issues.apache.org/bugzilla/show_bug.cgi?id=35256, >> it appears AllowEncodedSlashes hasn't worked right for some time, so >> there doesn't seem much point in fixing its config merging. >> >> Given the discussion in that bug, I'm wondering if AllowEncodedSlashes >> should just be deprecated or removed entirely. Thoughts? > > I think it sees a lot of use, so it would be nice to see how the > current behavior affects several modules (e.g. default/proxy/cgi (if > some use unparsed_uri maybe they could be misleading)) and fix the > doc then offer a "preserve" or "decode" option -- whichever isn't > happening now. Might even be useful to have an additional escape of > %2f as mentioned by wrowe in the PR. > > > -- > Eric Covener > cove...@gmail.com > -- Eric Covener cove...@gmail.com
millisecond timeouts in mod_proxy & mod_proxy_http
Apache committers: I'd like to submit this for possible inclusion in Apache httpd https://github.com/nealrichter/mod_proxy_http_sla - allows millisecond timeouts for ProxyPass/ProxyTimeout directives - allows millisecond timeouts for RewriteRule driven proxy - extends RewriteRules to implement a custom error document or return status per rule if timeout occurs Complete README here: https://github.com/nealrichter/mod_proxy_http_sla/blob/master/README We've been using both patches at the Rubicon Project for 18 months in one case and 6 in other. Handling billions of HTTP requests per day (yes really). Hat tip to Ronald Park who paved the way for this with similar work in httpd 2.0.x patches. Thanks - Neal Richter
Re: millisecond timeouts in mod_proxy & mod_proxy_http
It looks like it needs some fine-tuning and some formatting changes, but assuming we have CLA approval, I'd say lets fold it in and clean up post submission ;) On Jan 14, 2011, at 3:30 PM, Neal Richter wrote: > Apache committers: > > I'd like to submit this for possible inclusion in Apache httpd > > https://github.com/nealrichter/mod_proxy_http_sla > > - allows millisecond timeouts for ProxyPass/ProxyTimeout directives > - allows millisecond timeouts for RewriteRule driven proxy > - extends RewriteRules to implement a custom error document or return > status per rule if timeout occurs > > Complete README here: > https://github.com/nealrichter/mod_proxy_http_sla/blob/master/README > > We've been using both patches at the Rubicon Project for 18 months in > one case and 6 in other. Handling billions of HTTP requests per day > (yes really). > > Hat tip to Ronald Park who paved the way for this with similar work in > httpd 2.0.x patches. > > Thanks - Neal Richter >
Fwd: util_expr_parce.c
Forwarded on behalf of Gregg L. Smith (his email bounced 3 times for whatever reason). Original-Nachricht Hi Stefan, For some reason on Win we are falling through all the if(n)defs and are getting these ugly warnings; util_expr_parse.c(327) : warning C4273: 'malloc' : inconsistent dll linkage C:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdlib.h(601) : see previous definition of 'malloc' util_expr_parse.c(334) : warning C4273: 'free' : inconsistent dll linkage C:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdlib.h(600) : see previous definition of 'free' stdlib is being included in httpd.h since APR_HAVE_STDLIB_H == 1 in Win. May I suggest looking for it in util_expr_private.h and define _STDLIB_H there or any where/way you prefer. #if APR_HAVE_STDLIB_H #define _STDLIB_H #endif That rids us of the two ugliest warnings emitted from this parser. Regards, Gregg
