Re: Listen on UDS
I'd been musing, coincidentally, about being able to run httpd as a FastCGI. The motivation for this is a packaged webapp - Wordpress, say - that includes .htaccess files in the deployed package. Having the genuine Apache httpd able to serve the application and apply .htaccess restrictions would be a boon, even if the daemon listening on port 443 is different. -- Tim Bannister – is...@c8h10n4o2.org.uk
Re: *Match, RewriteRule POLA violation?
On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs apache-li...@riggs.me wrote: Thanks, Yann. I remember looking at this code before. The question remains, though: Is it currently wrong? Does it need to be fixed, or was this distinction made intentionally? Is there a specific use case that requires the regex-matching directives to not get slash-normalized URIs? I would like it to be fixed, non leading /+ is equivalent to /, this would break very few (if any) cases IMHO, and may even unbreak more ones .
Re: Proposal/RFC: informed load balancing
On Wednesday, April 29, 2015, Jim Riggs apache-li...@riggs.me mailto:apache-li...@riggs.me wrote: Warn out from writing all of this and hopeful that someone other than me actually cares, I wish you all well today/tonight! *Worn* out, even! Boy, I was tired!
Re: *Match, RewriteRule POLA violation?
On 28 Apr 2015, at 17:55, Yann Ylavic ylavic@gmail.com wrote:
It seems that while Location is compared to ap_no2slash(r-uri),
LocationMatch is matched against r-uri directly.
That's probably the issue.
A possible fix (untested) could be:
Index: server/request.c
===
--- server/request.c(revision 1674695)
+++ server/request.c(working copy)
@@ -1446,7 +1446,7 @@
pmatch = apr_palloc(rxpool, nmatch*sizeof(ap_regmatch_t));
}
-if (ap_regexec(entry_core-r, r-uri, nmatch, pmatch, 0)) {
+if (ap_regexec(entry_core-r, entry_uri, nmatch, pmatch, 0))
{
continue;
}
@@ -1456,7 +1456,7 @@
apr_table_setn(r-subprocess_env,
((const char
**)entry_core-refs-elts)[i],
apr_pstrndup(r-pool,
- r-uri + pmatch[i].rm_so,
+ entry_uri + pmatch[i].rm_so,
pmatch[i].rm_eo - pmatch[i].rm_so));
}
}
Thanks, Yann. I remember looking at this code before. The question remains,
though: Is it currently wrong? Does it need to be fixed, or was this
distinction made intentionally? Is there a specific use case that requires the
regex-matching directives to not get slash-normalized URIs?
On Mon, Apr 27, 2015 at 10:52 PM, Jim Riggs apache-li...@riggs.me wrote:
This came up at ApacheCon a couple of weeks ago. I just took this knowledge
for granted, as I have always accounted for it, but both Rich and Trawick
were surprised. As I thought about it some more, it seems this may be a POLA
violation. Thoughts? If we agree it should be fixed, I can make the bugz and
make a patch.
Consider:
Location /slash/foo
...
/Location
vs.
LocationMatch ^/slash/foo
...
/LocationMatch
These do not behave the same if multiple slashes are used. The leading
slashes are always coalesced, so ^/... is fine; however, any intermediate
slashes are not. So, in order for the LocationMatch directive above to
behave the same as the Location, it has to be specified as ^/slash/+foo.
Like I said, I have always accounted for this in my regexps, but it doesn't
seem right. Should the URL be normalized before being passed to
regex-matching directives, or is there a specific reason that is not done?
+---+--+--+--+
| Path | Non-Regex |*Match, |*Match, |
| | Directive: | RewriteRule: | RewriteRule: |
| | /slash/foo | ^/slash/foo | ^/slash/+foo |
+---+--+--+--+
| /slash/foo| Match| Match| Match|
+---+--+--+--+
| slash/foo | Match| Match| Match|
+---+--+--+--+
| /slash///foo | Match| XXX | Match|
+---+--+--+--+
| slash///foo// | Match| XXX | Match|
+---+--+--+--+
Re: [PATCH 0/5] Fix mod_websocket segfaults under load
On 3/9/2015 1:43 PM, Jacob Champion wrote: mod_websocket.c | 1005 +-- 1 file changed, 607 insertions(+), 398 deletions(-) Quick bump to this thread. Have any interested parties (Alex?) been able to give these patches a try? Any comments on coding style, architecture, etc.? And now for a really ambitious question: with enough cleanup and TLC, could this module ever be considered for support as an official module? If so, what would we need to put into it to get it there? If not, what are the objections? I'm particularly curious about thoughts on the threading architecture (one thread monopolized per WebSocket), the authorship concern (IIUC, ASF requires some trademark and/or other IP transfer, which may not be possible if the author is gone), and just the general question of should Apache support WebSockets out of the box? Does the answer to the last question change depending on the version of Apache (2.2, 2.4, 2.6)? Thanks! Jacob Champion LabVIEW RD National Instruments
Re: *Match, RewriteRule POLA violation?
+1 By unbreaking configurations we are indeed changing behavior. This could be an unexpected change for an admin during a minor upgrade but I weigh that against the fact that directives enclosed by these matches may be intended to add security/authorization/authentication which a badly written link could circumvent if an admin isn't using the appropriate regex. -- Daniel Ruggeri On 4/30/2015 8:16 AM, Yann Ylavic wrote: On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs apache-li...@riggs.me wrote: Thanks, Yann. I remember looking at this code before. The question remains, though: Is it currently wrong? Does it need to be fixed, or was this distinction made intentionally? Is there a specific use case that requires the regex-matching directives to not get slash-normalized URIs? I would like it to be fixed, non leading /+ is equivalent to /, this would break very few (if any) cases IMHO, and may even unbreak more ones .
Looking ahead to 2.4.13 / 2.2.30
On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Tue, 31 Mar 2015 10:49:47 -0400 Jim Jagielski j...@jagunet.com wrote: BTW: Would it make sense to consider a release of 2.4.13 in April to coincide w/ ApacheCon? We've historically produced a release at the beginning of the con. It worked really well when we would hackathon two days, then retire to do other con stuff for the balance of the event with a new release in the hopper looking for votes. I'd love to see us tag and roll releases based on our efforts throughout the entire gathering, sometime in that following week. I offer to TR an update of 2.2 as well to pick up any issues we resolve over the course of that week. It seems that we have 2 groups of good things to come out of ApacheCon, some immediate fixes for things like BSD project efforts, some pretty straightforward defects that have been resolved... and then there's a bunch of energy about enhancements and the h2 universe. In the short term, WDYT about giving the trees a week to settle, grab the low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming week? Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 in tandem. Concerns / observations / thoughts? Bill
Re: Proposal/RFC: informed load balancing
On 4/29/2015 11:54 PM, Jim Riggs wrote: [ Long message and proposal follows. Bear with me. There are a lot of words, but that is because we need a lot of help/input! ;-) ] So, this has come up in the past several times, and we discussed it again this year at ApacheCon: How do we get the load balancer to make smarter, more informed decisions about where to send traffic? The different LB methods provide some different attempts at balancing traffic, but ultimately none of them is smart about its decision. Other than a member being in error state, the balancer makes its decision solely based on configuration (LB set, factor, etc.) and its own knowledge of the member (e.g. requests, bytes). What we have often discussed is a way to get some type of health/load/capacity information from the backend to make informed balancing decisions. One method is to use health checks (a la haproxy, AWS ELBs, etc.) that request one or more URLs and the response code/time indicates whether or not the service is up and available, allowing more proactive decisions. While this is better than our current state of reactively marking members in error state based on failed requests, it still provides a limited view of the health/state of the backend. We have also discussed implementing a way for backends to communicate a magical load number to the front end to take into account as it balances traffic. This would give a much better view into the backend's state, but requires some way to come up with this calculation that each backend system/server/service/app must provide. This then has to be implemented in all the various backends (e.g. httpd, tomcat, php-fpm, unicorn, mongrel, etc., etc.), probably a hard sell to all of those projects. And, the front end would have limited control over what that number means or how to use it. During JimJag's balancer talk at ApacheCon this year, he brought up this issue of better, more informed decision making again. I put some thought into it that night and came up with some ideas. Jim, Covener, Trawick, Ruggeri, and I then spent some time over the next couple of days talking it through and fleshing out some of the details. Based on all of that, below is what I am proposing. I have some initial code that I am working on to implement the different pieces of this, and I will put them up in bugz or somewhere when they're a little less rudimentary. -- Our hope is to create a general standard that can be used by various projects, products, proxies, servers, etc., to have a more consistent way for a load balancer to request and receive useful internal state information from its backend nodes. This information can then be used by the *frontend* software/admin (this is the main change from what we have discussed before) to calculate a load factor appropriate for each backend node. This communication uses a new, standard HTTP header, X-Backend-Info, that takes this form in RFC2616 BNF: backend-info = version = numeric-entry [ *LWS , *LWS #( numeric-entry | string-entry ) ] numeric-entry = numeric-field = ( float | float ) ; that is, numbers may optionally be enclosed in ; quotation marks float = 1*DIGIT [ . 1*DIGIT ] numeric-field = workers-max ; maximum number of workers the backend supports | workers-used ; current number of used/busy workers | workers-allocated ; current number of allocated/ready workers | workers-free ; current number of workers available for use ; (generally the difference between workers-max and ; workers-used, though some implementations may have ; a different notion) | uptime ; number of seconds the backend has been running | requests ; number of requests the backend has processed | memory-max ; total amount of memory available in bytes | memory-used ; amount of used memory in bytes | memory-allocated ; amount of allocated/committed memory in bytes | memory-free ; amount of memory available for use (generally ; the difference between memory-max and memory-used, ; though some implementations may have a different ; notion) | load-current ; the (subjective) current load for the backend | load-5 ; the (subjective) 5-minute load for the backend |
