You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2016/01/12 19:13:09 UTC
mod_fcgid and broken doc links
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 - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
Re: mod_fcgid and broken doc links
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <rp...@apache.org> 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
Posted by Ruediger Pluem <rp...@apache.org>.
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
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Does it make sense to "officially" bundle mod_fcgid w/ httpd?
> On Jan 12, 2016, at 1:13 PM, Rich Bowen <rb...@rcbowen.com> 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 - rbowen@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
Re: mod_fcgid and broken doc links
Posted by Mike Rumph <mi...@oracle.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
There is a need and an audience for both. We provide
both. I see no reason for us to stop doing that unless
we feel that we can no longer support both in the
manner in which our community expects. FWIW, I don't
see that as the current situation.
> On Jan 18, 2016, at 9:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> > >
> > > 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.
> >
> > -1
> >
> > You are implying that one would be a winner in all cases. The
> > whole idea is that there are cases where one is better than
> > the other. We provide both.
> >
> > You might have made that inference, but I'm going to assert that
> > for this one module, for s/{literal}/{repl}, mod_sed is going to
> > outperform mod_substitute /if/ we wrote the code correctly.
>
> I disagree... it's kind of obvious by simple inspection that
> mod_substitute has fast paths that mod_sed lacks and, as thus,
> can be quite performant and the "better" choice in numerous cases
> where that fast path is used.
>
> Well, only benchmarking is going to prove that one way or the other,
> something I don't have free cycles for right now (committed to way too
> many other project priorities.) And it perhaps opens up opportunities
> to optimize mod_sed in ways that might have been initially overlooked
> when the code was thrown into trunk ;-)
>
> Me, I don't tend to think of myself as "smarter" than all of
> our users, nor do I try to act as Big Brother and remove choices
> from people in cases and situations where they are using them.
> The ASF itself doesn't do that, nor do projects... so it seems
> kinda weird that you would want the httpd project to all of
> a sudden start removing choice and options for end users instead
> of helping them out and trusting them to know which impl is
> best for them.
>
> Thankfully, we aren't, but our users do look at us as experts in the
> code they consume, considering that we collectively have authored
> and maintain the stuff. So they do look to us to make the best
> choices they don't have the individual time to compare and elect.
> Why would I want us to collectively (and for me specifically) to
> propose the best solutions to the common use cases, and to
> depreciate less maintained code in favor of maintained code?
>
> Can't imagine why I or other project members would be possessed
> to do that. If you figure it out, please share :)
Re: mod_fcgid and broken doc links
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > >
> > > 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.
> >
> > -1
> >
> > You are implying that one would be a winner in all cases. The
> > whole idea is that there are cases where one is better than
> > the other. We provide both.
> >
> > You might have made that inference, but I'm going to assert that
> > for this one module, for s/{literal}/{repl}, mod_sed is going to
> > outperform mod_substitute /if/ we wrote the code correctly.
>
> I disagree... it's kind of obvious by simple inspection that
> mod_substitute has fast paths that mod_sed lacks and, as thus,
> can be quite performant and the "better" choice in numerous cases
> where that fast path is used.
>
Well, only benchmarking is going to prove that one way or the other,
something I don't have free cycles for right now (committed to way too
many other project priorities.) And it perhaps opens up opportunities
to optimize mod_sed in ways that might have been initially overlooked
when the code was thrown into trunk ;-)
> Me, I don't tend to think of myself as "smarter" than all of
> our users, nor do I try to act as Big Brother and remove choices
> from people in cases and situations where they are using them.
> The ASF itself doesn't do that, nor do projects... so it seems
> kinda weird that you would want the httpd project to all of
> a sudden start removing choice and options for end users instead
> of helping them out and trusting them to know which impl is
> best for them.
>
Thankfully, we aren't, but our users do look at us as experts in the
code they consume, considering that we collectively have authored
and maintain the stuff. So they do look to us to make the best
choices they don't have the individual time to compare and elect.
Why would I want us to collectively (and for me specifically) to
propose the best solutions to the common use cases, and to
depreciate less maintained code in favor of maintained code?
Can't imagine why I or other project members would be possessed
to do that. If you figure it out, please share :)
Re: mod_fcgid and broken doc links
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 18, 2016, at 3:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > 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.
>
> -1
>
> You are implying that one would be a winner in all cases. The
> whole idea is that there are cases where one is better than
> the other. We provide both.
>
> You might have made that inference, but I'm going to assert that
> for this one module, for s/{literal}/{repl}, mod_sed is going to
> outperform mod_substitute /if/ we wrote the code correctly.
I disagree... it's kind of obvious by simple inspection that
mod_substitute has fast paths that mod_sed lacks and, as thus,
can be quite performant and the "better" choice in numerous cases
where that fast path is used.
Me, I don't tend to think of myself as "smarter" than all of
our users, nor do I try to act as Big Brother and remove choices
from people in cases and situations where they are using them.
The ASF itself doesn't do that, nor do projects... so it seems
kinda weird that you would want the httpd project to all of
a sudden start removing choice and options for end users instead
of helping them out and trusting them to know which impl is
best for them.
Re: mod_fcgid and broken doc links
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > 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.
>
> -1
>
> You are implying that one would be a winner in all cases. The
> whole idea is that there are cases where one is better than
> the other. We provide both.
>
You might have made that inference, but I'm going to assert that
for this one module, for s/{literal}/{repl}, mod_sed is going to
outperform mod_substitute /if/ we wrote the code correctly. Whas
is missing is a mod_sed directive for adding literal s/{orig}/{repl}/
patterns that follows the substitute syntax and that admins don't
have to wrap their heads around the special character escaping.
At that point, there is no reason for the redundant module, but
we aren't at that point.
Would you also recommend such a scenario with MPMs, and
> having the "winner" take all? I certainly hope not!!!
>
No, I generally agree with TMTOWTDI. Glad you raised the MPMs
issue, because my exact complaint about folding in mod_fcgid
"as is" and overlapping with mod_proxy_fcgi was addressed by the
MPM community in pulling out and sharing the mpm_common.c
logic. Great example, thanks Jim!
Re: mod_fcgid and broken doc links
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 14, 2016, at 5:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>
> 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.
-1
You are implying that one would be a winner in all cases. The
whole idea is that there are cases where one is better than
the other. We provide both.
Would you also recommend such a scenario with MPMs, and
having the "winner" take all? I certainly hope not!!!
Re: mod_fcgid and broken doc links
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 14, 2016 at 6:19 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 13, 2016, at 12:28 PM, William A Rowe Jr <wr...@rowe-clan.net>
> 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: mod_fcgid and broken doc links
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 13, 2016, at 12:28 PM, William A Rowe Jr <wr...@rowe-clan.net> 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: mod_fcgid and broken doc links
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jan 13, 2016 15:50, "Rich Bowen" <rb...@rcbowen.com> 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
Posted by Rich Bowen <rb...@rcbowen.com>.
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 - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
Re: mod_fcgid and broken doc links
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jan 12, 2016 at 12:13 PM, Rich Bowen <rb...@rcbowen.com> 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.