Re: mod_fcgid and broken doc links
On Thu, Jan 14, 2016 at 6:19 AM, Jim Jagielski wrote: > > > On Jan 13, 2016, at 12:28 PM, William A Rowe Jr > wrote: > > > > I can see us moving those modules into trunk (not 2.4), retaining the > > mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release > > out of trunk/modules/fcgid/. But I'm not clear why we would want to > > maintain the duplication between mod_proxy_fcgi and mod_fcgid? > > Individually they get little enough attention as it is. > > Because they are separate solutions to a similar problem, > ala mod_sed and mod_substitute for example. I can site several > more if that is worthwhile (but the point is made) mod_fcgid does > not require the whole mod_proxy overhead, for example, but > lacks some features that mod_proxy_fcgi does have, since the > latter can leverage some of that "overhead". Good point with your example, this is something that should be benchmarked and the winner-take-all, loser bumped from the trunk/ copy of httpd. They are slightly different in that sed is one specific grammar, while substitute uses literal replacements, but that could be a syntax tweak to mod_sed to allow some literal replacements. In any case, it relieves the dozen or so regular httpd contributors from maintaining two modules which do, for the most part, the very same thing expressed with redundant yet different code. Likewise with fcgid/proxy_fcgi - /if/ we bring mod_fcgid sources into the trunk, I'd add the caveat that we do so if there is an offer to eliminate all of the code duplication in the process, or reject this proposition. They do perform two different purposes and overlap in interesting ways, so there has to be something gained by pushing fcgid upon the entire httpd committer community to maintain. It was one thing for the handful of us who commit to mod_fcgid to deal with that legacy, but another to push it mainstream. > > Just my 2c USD, I'm open to ideas. > > That is good to know. Was simply offering backstory for why things ended up as they have, sans snark, and no snark needed in response :) Would love to learn who is interested in helping merge mod_fcgid and mod_proxy_ftp functionality into a util_fcgi, or otherwise condense this functionality into something manageable, long term.
Re: access control for dynamic hosts
Hello Mario, doesn't it work using Require host with a dyndns name? From the documentation about "Require host ...": "It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed." So the reverse DNS must work. A benefit is that it allows to check for a full domain. Note that the source code seems to say the same, although in C:-) At least my test was successful. I'm surprised. I just tested it again from my home (which use a dynamic dns), and it did not work with "Require host" in a context, with "Require host NNN": sh> netcat 3128 GET http://www.google.fr/ HTTP/1.0 HTTP/1.1 403 Forbidden ... So the client was not authorized, but after a reload with a "Require name NNN" from the submitted module: sh> netcat 3128 GET http://www.google.fr/ HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 14 Jan 2016 21:30:40 GMT Server: gws ... Maybe the reverse dns is working on your test address? -- Fabien.
Re: help from cache gurus?
I'll have some time over the weekend... > On Jan 14, 2016, at 10:25 AM, Eric Covener wrote: > > Review please? Didn't want unnecessary churn in svn. > > http://people.apache.org/~covener/patches/httpd-trunk-cachecontrol.diff > > (whitespace not included) > > I think the changing meaning of "exp" over time in that function adds > to the confusion, but pre-patch the issue is that we do not give > Cache-Control s-maxage and max-age priority over Expires (either when > checking if we can cache or determining our own expiry) > > The patch is really three tiightly coupled fixes around s-maxage. > > Can anyone review / kick the tires? > -- > Eric Covener > cove...@gmail.com
help from cache gurus?
Review please? Didn't want unnecessary churn in svn. http://people.apache.org/~covener/patches/httpd-trunk-cachecontrol.diff (whitespace not included) I think the changing meaning of "exp" over time in that function adds to the confusion, but pre-patch the issue is that we do not give Cache-Control s-maxage and max-age priority over Expires (either when checking if we can cache or determining our own expiry) The patch is really three tiightly coupled fixes around s-maxage. Can anyone review / kick the tires? -- Eric Covener cove...@gmail.com
Re: Work in progress: mod_proxy Health Check module
On Dec 30, 2015 4:21 AM, "Jim Jagielski" wrote:
> Just a note that I've started committing my mod_proxy health
> check module work... it is still a work-in-progress but the
> goal is to always ensure that trunk is buildable and usable.
> Right now, the module needs to be explicitly enabled during
> configuration and all specific health-checks are basically
> noops.
>
> My design thoughts are that for each scheme/protocol allowed,
> the (sub)module that handles that (eg: mod_proxy_http, mod_proxy_ajp,
> etc...) implements an optional function that does the actual
> server call. What constitutes a "success" is also up for
> discussion. I've been mulling over having the check return
> the response headers which can then be checked/verified using
> our Expression routines ala . eg:
>
> Condition all_good "%{REQUEST_STATUS} in { '200', '304' }"
>
> And there is a 'check' mini-directive:
>
> BalancerMember http://www.example.com/ method=get check=all_good
>
> which uses the stored condition for the pass/fail test.
>
Re: mod_fcgid and broken doc links
> On Jan 13, 2016, at 12:28 PM, William A Rowe Jr wrote: > > > I can see us moving those modules into trunk (not 2.4), retaining the > mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release > out of trunk/modules/fcgid/. But I'm not clear why we would want to > maintain the duplication between mod_proxy_fcgi and mod_fcgid? > Individually they get little enough attention as it is. > Because they are separate solutions to a similar problem, ala mod_sed and mod_substitute for example. I can site several more if that is worthwhile (but the point is made) mod_fcgid does not require the whole mod_proxy overhead, for example, but lacks some features that mod_proxy_fcgi does have, since the latter can leverage some of that "overhead". > Just my 2c USD, I'm open to ideas. That is good to know.
Re: Work in progress: mod_proxy Health Check module
> Am 09.01.2016 um 19:18 schrieb Jim Jagielski : > > Here is the general concept: > > The health check itself is done via mod_watchdog, and uses > its callback impl. Each worker will have its own check interval, > which can be changed via the new balancer member directives > (hcinterval=, hcfails=,...); these will also be changable via > the balancer manager. > > There will be a set of health checks available, depending on > the scheme of the backend. There will be: > > None > TCP: a simple 'is socket up check' > OPTIONS: for http only > HEAD: http only, sends HEAD /... > GET: http only, sends GET /... > CPING: ajp cping/cpong For completeness: HTTP/2 has a PING frame. And, yes, I might make an attempt at a http2 proxy modding sometime soon... >:-) -Stefan
Re: AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE
Hi Nick, Am 13.01.2016 22:44, schrieb Nick Kew: PROBLEM DESCRIPTION This is probably worth a bugzilla entry. Done. https://bz.apache.org/bugzilla/show_bug.cgi?id=58856 Nick, would you mind to provide some insights on these comments from my initial mail: For setups with both, FilterDeclare and AddOutputFilterByType (as described above as fix), I observed some issues with properly merging the two filter harnesses. However, I have no clue what semantics the original author wanted to have in this situation. Assumed that my patch gets applied, the filter type should be correctly set in the filter harness. But what if a user wants to override it? I got a few questions in this context: 1.) Should "FilterDeclare" with filter-name "BYTYPE:DEFLATE" (i.e. colliding with the implicit filter-name created by AddOutputFilterByName) be supported at all? 1a.) If yes, the handling of AddOutputFilterByType needs to be fixed so that: - a globally configured FilterDeclare is also effective for an AddOutputFilterByType within a (location) sub-container. - a filter type set by "FilterDeclare BYTYPE: type>" does not get overwritten by a subsequent "AddOutputFilterByType ". 1b.) If no, the code should detect and reject such configurations. 2.) On a related note to 1., Should FilterDeclare allow a filter-name of existing filter providers at all? If yes, behavior would we expect? Nick, I would be really glad if you could share your thoughts. Best regards, Micha
Re: access control for dynamic hosts
Hi Fabien, doesn't it work using Require host with a dyndns name? At least my test was successful. Cheers Mario On 20 December 2015 at 09:44, Fabien wrote: > > Hello folks, > > I have a simple access control use case for which I have not found a clean > solution. > > I want to control access to a service based on the name of the client, > however the client is a dynamic host, which implies that: > > (1) I do not have any control about the reverse DNS > => this rules out "Require host" > > (2) the IP may change arbitrarily > => this rules out "Require ip" > > By browsing around it seems that I'm not alone having this issue, and I have > not found any solution for that with apache configuration, nor a matching > module in "modules.apache.org" listing. > > The current workaround is to update the IP manually when it fails. Although > I could automate (say query the ip periodically and update & reload the conf > if there is a change), ISTM that it really belongs to apache configuration. > > I would like something like "Require XXX foo.dynamic-dns.somewhere" (where > XXX could be "name", "hostname", "dynamic", ...) which would query the NS > when the HTTP request is received and check that the corresponding ip is the > client IP. > > I'm planing to develop a small module for that, and as it is somehow quite a > basic service it could be a candidate for being added to > "modules/aaa/mod_authz_host.c". > > Another approach could be to extend apache expressions with a function > to query the DNS, but that seems a little overkill. > > Any thoughts? > > -- > Fabien.
Re: access control for dynamic hosts
Hello Apache devs, Would anyone have an opinion, please? Although I can just commit the proposed changes, a formal go would be nice. On Sun, 20 Dec 2015, Fabien wrote: Date: Sun, 20 Dec 2015 09:44:55 +0100 (CET) From: Fabien Reply-To: dev@httpd.apache.org To: APACHE development mailing list Subject: access control for dynamic hosts Hello folks, I have a simple access control use case for which I have not found a clean solution. I want to control access to a service based on the name of the client, however the client is a dynamic host, which implies that: (1) I do not have any control about the reverse DNS => this rules out "Require host" (2) the IP may change arbitrarily => this rules out "Require ip" By browsing around it seems that I'm not alone having this issue, and I have not found any solution for that with apache configuration, nor a matching module in "modules.apache.org" listing. The current workaround is to update the IP manually when it fails. Although I could automate (say query the ip periodically and update & reload the conf if there is a change), ISTM that it really belongs to apache configuration. I would like something like "Require XXX foo.dynamic-dns.somewhere" (where XXX could be "name", "hostname", "dynamic", ...) which would query the NS when the HTTP request is received and check that the corresponding ip is the client IP. I'm planing to develop a small module for that, and as it is somehow quite a basic service it could be a candidate for being added to "modules/aaa/mod_authz_host.c". Another approach could be to extend apache expressions with a function to query the DNS, but that seems a little overkill. Any thoughts? -- Fabien.
Re: [Bug 55808] File integrity verification using MD5 and SHA1
[cross posting @docs => @dev, full thread http://www.gossamer-threads.com/lists/apache/docs/453401] On Thu, Jan 14, 2016 at 1:50 AM, Tom Fredrik Blenning Klaussen wrote: > > On 14/01/16 01:19, Yann Ylavic wrote: >> >> as I said earlier, the way you access the >> tarball is not that important provided you verify its signature, or >> its digests from the official repository only. > > I understand what you are saying that the proper way is to download > the checksums from the correct source, which is self-evident. Now > assume you're a new user, and do not have this previous knowledge. > This user is security conscious, so the user chooses https on purpose. > He would go into (https://httpd.apache.org), where he would find a > link taking him to (https://httpd.apache.org/download.cgi), at this > point, he would find the link to (http://www.apache.org/dist/httpd/), > what I'm saying is in order to have some trust in that link, it > _SHOULD_ be https otherwise assuming you could introduce yourself as a > MitM, manipulating the signatures would be trivial. OK, I thought the links to the MD5/SH1/PGP were https: but this is not the case. I agree that the origin of these files should be trustable. @dev: should I s/http:/https:/ for those links (only) in ^httpd/site/trunk/content/download.mdtext? Or possibly use paths instead (i.e. /dist/httpd/...) so that it depends on /download.cgi is accessed? Would that be enough for the prod to be updated (via staging)? Regards, Yann.
