Re: mod_fcgid and broken doc links

[Jim Jagielski]

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

Re: mod_fcgid and broken doc links

[Jan Ehrhardt]

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: AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE

[Nick Kew]

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

[Rich Bowen]

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: mod_fcgid and broken doc links

[William A Rowe Jr]

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

[Ruediger Pluem]

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

[Mike Rumph]

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

[Jim Jagielski]

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
> 

AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE

[Micha Lenk]

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, , 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

[William A Rowe Jr]

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.