Re: mod_fcgid and broken doc links
On Jan 13, 2016 15:50, "Rich Bowen" wrote: > > Yes, it would be nice to merge them, from the perspective of explaining > things to users. Guess I am still confused what you suggest to merge... Docs or both docs and code... Also curious about released vs unreleased with respect to docs. Our pointers and resources for developers mostly live under http://httpd.a.o/dev/ per ASF policy, but docs is an exception. We are supposed to be pointing users at the released artifacts, and not at unreleased drafts. Even http://httpd.apache.org/docs/dev/ might be clearer than trunk/ for those who stumble upon them. Thoughts?
Re: mod_fcgid and broken doc links
On 01/13/2016 12:28 PM, William A Rowe Jr wrote: > The reason for mod_ftp and mod_fcgid separate builds was historically > that the same module, releasing on a different calendar than httpd, have > been build-able independently against 2.0, 2.2 or 2.4. Maintaining the > sources across the different branches was also something of a PITA. > > Maybe more significantly, mod_proxy_fcgi was our 'adopted' solution > to the fcgi case. mod_fcgid is a different beast with process pool > management. I was always under the impression that for 2.4 and later, > we collectively wanted to express process pools independently of the > mod_proxy_fcgi structure, much like we and tomcat would love to see > folks use mod_proxy_http or _ajp rather than mod_jk. > > mod_ftp clearly isn't http:// so it never quite felt appropriate in that > tree, but then again neither is mod_proxy_ajp :) Which goes to the > gist of it all, code bloat. We've successfully only killed a tiny handful > of modules in our entire history (imagemap, mem_cache etc). mod_imagemap still lives on in trunk. As does mod_cern_meta. Point taken. > So once merge to trunk, we own that code bloat for a very long time, > but if it exists separate these can be enhanced or retired based on > our desires. E.g. if mod_aspdotnet had lived in modules/os/win32/ > we would still probably be shipping it, irrespective of how out of date > that module becomes. > > 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. Yes, it would be nice to merge them, from the perspective of explaining things to users. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE
On Wed, 2016-01-13 at 17:59 +0100, Micha Lenk wrote: > Hi, > > The directive AddOutputFilterByType can be used to insert filters to the > output filter chain depending on the content type of the HTTP response. > So far so good. > > PROBLEM DESCRIPTION This is probably worth a bugzilla entry. I think I can clarify a little of what's happened. AddOutputFilterByType was something of a hacked afterthought to filtering back in the days of httpd 2.0. On the one hand, it met a need. On the other hand, it worked only in a very limited range of situations where the content type was known at the time the filter was to be added. It had no capacity to respond to other aspects of the content, or indeed the request/response. And there were other issues. Then came mod_filter and a generalised framework. AddOutputFilterByType was now obsolete, but too widely-used to dispense with entirely. As a compromise it was re-implemented within mod_filter, where it could co-exist with other dynamic filter configuration. Your observation tells us the semantics aren't quite compatible. And your patch looks good - thanks. -- Nick Kew
Re: mod_fcgid and broken doc links
On Tue, Jan 12, 2016 at 12:13 PM, Rich Bowen wrote: > mod_fcgid is in a separate repo from the main httpd tree, due to > historical reasons. I presume there are good reasons for this. JimJag > suggested on IRC it's due to its independent release cycle. > > Be that as it may, because it uses the standard documentation tools for > the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html > is full of broken links. In particular, try any of the directive and > links to other modules - try the mod_cgi or AddHandler links in the > intro paragraph, and you'll see immediately what the problem is. > > Now, we could of course have a separate version of the docs building > tools just for this module, or we could patch the doc manually, but I > was wondering, if there's no strong current reason for the module to be > kept separate, can we please move it into the main httpd tree? > The reason for mod_ftp and mod_fcgid separate builds was historically that the same module, releasing on a different calendar than httpd, have been build-able independently against 2.0, 2.2 or 2.4. Maintaining the sources across the different branches was also something of a PITA. Maybe more significantly, mod_proxy_fcgi was our 'adopted' solution to the fcgi case. mod_fcgid is a different beast with process pool management. I was always under the impression that for 2.4 and later, we collectively wanted to express process pools independently of the mod_proxy_fcgi structure, much like we and tomcat would love to see folks use mod_proxy_http or _ajp rather than mod_jk. mod_ftp clearly isn't http:// so it never quite felt appropriate in that tree, but then again neither is mod_proxy_ajp :) Which goes to the gist of it all, code bloat. We've successfully only killed a tiny handful of modules in our entire history (imagemap, mem_cache etc). So once merge to trunk, we own that code bloat for a very long time, but if it exists separate these can be enhanced or retired based on our desires. E.g. if mod_aspdotnet had lived in modules/os/win32/ we would still probably be shipping it, irrespective of how out of date that module becomes. 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. Just my 2c USD, I'm open to ideas.
AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE
Hi, The directive AddOutputFilterByType can be used to insert filters to the output filter chain depending on the content type of the HTTP response. So far so good. PROBLEM DESCRIPTION I observed that the behavior of this directive changed in Apache 2.4 for filters. Starting with Apache 2.4 filters are inserted at an earlier place in the filter chain than they were inserted with Apache 2.2. For example, if you use the directive AddOutputFilterByType DEFLATE text/html The filter is inserted with AP_FTYPE_RESOURCE, even though it was registered in mod_deflate.c as AP_FTYPE_SET_CONTENT. The effect is that using "AddOutputFilterByType DEFLATE text/html" the resulting filter chain is ordered diferrently compared to using "SetOutputFilter DEFLATE". This can be fixed in configuration by adding the following directive right after AddOutputFilterByType: FilterDeclare BYTYPE:DEFLATE CONTENT_SET Unfortunately the order and placement of FilterDeclare seems to be relevant, i.e. this fix only works if FilterDeclare comes *after* AddOutputFilterByType within the same container. I wonder whether this is an intentional behavior change of AddOutputFilterByType or not. ANALYSIS Apparently the filter type (ap_filter_rec_t struct member ftype) of the filter provider isn't respected anymore. The intended filter type is provided when registering the output filter by calling ap_register_output_filter(). In branch 2.2.x this was sufficient, because the conditional filter (based on the MIME type) was added directly by name (i.e. by calling ap_add_output_filter() in ap_add_output_filters_by_type). In branches 2.4.x and trunk the implementation of AddOutputFilterByType apparently moved to mod_filter and a layer of indirection (the filter harness) is introduced. But the filter harness is apparently created unconditionally with AP_FTYPE_RESOURCE. FIX APPROACH When implicitly creating a filter harness by calling the function add_filter(), we have access to the provider's ap_filter_rec_t anyways. So I recommend to just copy it from the filter provider (e.g. DEFLATE) to the filter harness (e.g. BYTYPE:DEFLATE). I've tested this approach with the patch below for a setup without any FilterDeclare directive, and it fixed the regression; the DEFLATE filter was ordered correctly at AP_FTYPE_CONTENT_SET again. - 8>< -- diff --git a/modules/filters/mod_filter.c b/modules/filters/mod_filter.c index 7b69223..5b5ecf6 100644 --- a/modules/filters/mod_filter.c +++ b/modules/filters/mod_filter.c @@ -444,6 +444,12 @@ static const char *add_filter(cmd_parms *cmd, void *CFG, ap_expr_info_t *node; const char *err = NULL; +/* if provider has been registered, we can look it up */ +provider_frec = ap_get_output_filter_handle(pname); +if (!provider_frec) { +return apr_psprintf(cmd->pool, "Unknown filter provider %s", pname); +} + /* fname has been declared with DeclareFilter, so we can look it up */ frec = apr_hash_get(cfg->live_filters, fname, APR_HASH_KEY_STRING); @@ -454,17 +460,13 @@ static const char *add_filter(cmd_parms *cmd, void *CFG, return c; } frec = apr_hash_get(cfg->live_filters, fname, APR_HASH_KEY_STRING); +frec->ftype = provider_frec->ftype; } if (!frec) { return apr_psprintf(cmd->pool, "Undeclared smart filter %s", fname); } -/* if provider has been registered, we can look it up */ -provider_frec = ap_get_output_filter_handle(pname); -if (!provider_frec) { -return apr_psprintf(cmd->pool, "Unknown filter provider %s", pname); -} provider = apr_palloc(cmd->pool, sizeof(ap_filter_provider_t)); if (expr) { node = ap_expr_parse_cmd(cmd, expr, 0, &err, NULL); - 8>< -- 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. I hope my explanations are clear enough for others to follows. If not, please don't hesitate to ask. Best regards, Micha
Re: mod_fcgid and broken doc links
Not just for that, but to make it easier for people to use it... Seems stable enough that making it a bundled module makes sense. > On Jan 13, 2016, at 9:43 AM, Ruediger Pluem wrote: > > > > On 01/13/2016 01:33 PM, Jim Jagielski wrote: >> Does it make sense to "officially" bundle mod_fcgid w/ httpd? > > Just for fixing the documention? > In this case I would prefer to investigate other solutions for the > documentation and keep it separate. > > Regards > > RĂ¼diger >
Re: mod_fcgid and broken doc links
A background for this request can be seen in bug report 56121. - https://bz.apache.org/bugzilla/show_bug.cgi?id=56121#c4 This bug also describes a manual method for working around this problem. On 1/12/2016 10:13 AM, Rich Bowen wrote: mod_fcgid is in a separate repo from the main httpd tree, due to historical reasons. I presume there are good reasons for this. JimJag suggested on IRC it's due to its independent release cycle. Be that as it may, because it uses the standard documentation tools for the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html is full of broken links. In particular, try any of the directive and links to other modules - try the mod_cgi or AddHandler links in the intro paragraph, and you'll see immediately what the problem is. Now, we could of course have a separate version of the docs building tools just for this module, or we could patch the doc manually, but I was wondering, if there's no strong current reason for the module to be kept separate, can we please move it into the main httpd tree? (Note that exactly the same situation applies to mod_ftp, but there's just fewer links from that doc so we don't hear it as often.) --Rich
Re: mod_fcgid and broken doc links
On 01/13/2016 01:33 PM, Jim Jagielski wrote: > Does it make sense to "officially" bundle mod_fcgid w/ httpd? Just for fixing the documention? In this case I would prefer to investigate other solutions for the documentation and keep it separate. Regards RĂ¼diger
Re: mod_fcgid and broken doc links
Jim Jagielski in gmane.comp.apache.devel (Wed, 13 Jan 2016 07:33:43 -0500): >Does it make sense to "officially" bundle mod_fcgid w/ httpd? FWIW: I always compile mod_fcgid.so together with Apache httpd. I have made it part of my VC 9/11/14 solution files. I guess that many Windows users of httpd install mod_fcgid, so for them it makes sense. Jan
Re: mod_fcgid and broken doc links
Does it make sense to "officially" bundle mod_fcgid w/ httpd? > On Jan 12, 2016, at 1:13 PM, Rich Bowen wrote: > > mod_fcgid is in a separate repo from the main httpd tree, due to > historical reasons. I presume there are good reasons for this. JimJag > suggested on IRC it's due to its independent release cycle. > > Be that as it may, because it uses the standard documentation tools for > the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html > is full of broken links. In particular, try any of the directive and > links to other modules - try the mod_cgi or AddHandler links in the > intro paragraph, and you'll see immediately what the problem is. > > Now, we could of course have a separate version of the docs building > tools just for this module, or we could patch the doc manually, but I > was wondering, if there's no strong current reason for the module to be > kept separate, can we please move it into the main httpd tree? > > (Note that exactly the same situation applies to mod_ftp, but there's > just fewer links from that doc so we don't hear it as often.) > > --Rich > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon