From: Jakub Narebski <jnareb@gmail•com>
To: Peter Vereshagin <peter@vereshagin•org>
Cc: Petr Baudis <pasky@suse•cz>, Eric Wong <normalperson@yhbt•net>,
git@vger•kernel.org, Sam Vilain <sam.vilain@catalyst•net.nz>,
Juan Jose Comellas <juanjo@comellas•org>,
John Goerzen <jgoerzen@complete•org>
Subject: Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script
Date: Tue, 11 May 2010 15:51:15 +0200 [thread overview]
Message-ID: <201005111551.21316.jnareb@gmail.com> (raw)
In-Reply-To: <20100511120924.GC5220@screwed.box>
On Tue, 11 May 2010, Peter Vereshagin wrote:
> 2010/05/11 12:58:50 +0200 Jakub Narebski <jnareb@gmail•com> => To Peter Vereshagin :
> > > > I have changed this 'exit' to non-local goto to toplevel. It could be
> > > > done instead by redefining 'exit' subroutine, like shown below, but I
> > > > feel that would be hacky if you can change gitweb code (it is not
> > > > black box you should not touch).
> > >
> > > Right, one shouldn't ever redefine perl built-in functions. I did only because
> > > of no other way to 'get things working'
> >
> > Why not? For example CGI::Carp redefines 'die' to log errors.
>
> Ouch, sorry, I meant 'last' or something like that.
"last" / "last LABEL" is a command, not a function, therefore you cannot
redefine it.
Well, perhaps you can with heavy hackery involving opcodes and the like,
or something debugger-like, or/and something like B::* modules, taking
over Perl parser. See e.g. Devel::Declare or Template::Declare Perl
modules on CPAN. :-)
> I just believe any non-system application development for end-user being a
> non-developer doesn't need to redefine perl built-in functions. Just a sane
> bone tone for common functioning in a sandbox.
>
> For example, I remember the Linux kernel ( or Glibc? ) was criticised much of
> being possible to override the str*cmp() inside. Because most of the existing
> commerceware were protected from copying by password, e. g. serial number, etc.
> sometimes by authors. So criticants supposed it's impossible to 'protect' their
> software this way. And thus Linux was 'bad'. ;-)
What about libsafe (?) and similar security solutions, which replace
str* functions from (g)libc with safer but slower counterparts? What
about Dmalloc, Electric Fence and the like which replace malloc etc.?
> So one who use CORE:: namespace in their sources should always know it can be
> grepped and considered as dangerous, especially if those are 3rd+ party
> sources, not approved by any reasonable authority, and there are lots of such a
> software off the shelves to choose. And most of them doesn't use to override
> perl built-in functions. ;-)
It is true that messing with / overriding things from CORE:: (or
UNIVERSAL:: for OOP) namespace is dangerous, and should be avoided if
possible... but well, sometimes it is a best solution.
> > I know this from painful experience of trying to find bug in a
> > test... when the error was in parsing file in 'do $file;'.
>
> I handle them just fine like in any other CGI program using
> CGI::Carp:fatalsToBrowser. Are you about to 'make test' via the http? ;-)
I don't think you understand what I wanted to say there.
If you don't check if there were parse errors from 'do $file;', you can
get later some error message which is totally unrelated to the parsing
error. If you don't know or forget that you should check $@ after
'do $file;', and are unlucky, you can chase elusive error from there
to kingdom come...
For example when debugging gitweb output caching code using automated
tests, I got the following error:
'Undefined subroutine &GitwebCache::SimpleFileCache::compute called'
The subroutine was defined, but there was a bug in parsing included
file, so Perl didn't make it to definition of said compute() subroutine.
> [...]
>
> > builder {
> > $app;
> > }
>
> that's the wow to try. I will after some of my whiles.
Check out http://plackperl.org, especially presentations and Perl Advent
Calendar which describes PSGI/Plack step by step (links at the bottom of
the page).
> > or even without it ($app should be the last expression).
> > Or did you mean here something like mod_rewrite, or
> > Plack::Middleware::Rewrite?
>
> No, nginx rewrites just fine, it's a matter of another application level I
> believe.
>
> The scoop is meat and potatoes: here is the CGI app, just do it over FastCGI.
> There are no such a thing as a mandatory mounts and paths tweaks in PHP's
> FastCGI. Hope PSGI has no them either.
PSGI is interface, Plack is reference implementation. You can run PSGI
app on any supported web server; this includes running PSGI apps on
FastCGI.
> > > > Gitweb doesn't use no POST requests: it is read-only web repository
> > > > browser... well, except for the 'show_ctags' action.
> > >
> > > Tag cloud? Is there an example of usable tag cloud on any public gitweb out
> > > there?
> >
> > Tag cloud are optional feature in stock gitweb, named 'ctag' in %feature
> > hash. It is disabled by default. If I understand correctly POST is
> > used here to populate which tags one wants to use... but perhaps GET
> > request would be enough here (at the cost of less readable URL).
> >
> > See http://repo.or.cz for example usage of this feature.
>
> Ouch, it was the first for me to look for them. It's just not named like that
> there ( and looked like linkspam ;-. Anyway. user registration .cgi is a part
> of gitweb distribution? It contains POST form and it's not preferable stuff to
> omit for too many cases to consider such a gitweb-based web site to be 'mostly
> read-only' for a user.
>
> Or those .cgi's are nothing in common with gitweb?
The repository management part of http://repo.or.cz is not part of
gitweb. It is a separate tool, named Girocco.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2010-05-11 13:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 12:54 [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script Jakub Narebski
2010-05-07 12:54 ` [PATCH/RFC 1/2] gitweb: Put all per-connection code in run() subroutine Jakub Narebski
2010-05-07 12:54 ` [RFC/PATCH 2/2] gitweb: Add support for FastCGI, using CGI::Fast Jakub Narebski
2010-05-08 7:59 ` [RFC/PATCHv2 " Jakub Narebski
2010-05-08 22:41 ` [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script Jakub Narebski
2010-05-09 9:31 ` Eric Wong
2010-05-09 11:48 ` Ævar Arnfjörð Bjarmason
2010-05-09 12:39 ` Jakub Narebski
2010-05-09 16:47 ` Peter Vereshagin
2010-05-09 18:18 ` Jakub Narebski
2010-05-10 7:13 ` Peter Vereshagin
2010-05-10 15:29 ` Jakub Narebski
2010-05-11 6:24 ` Peter Vereshagin
2010-05-11 8:35 ` Petr Baudis
2010-05-11 10:58 ` Jakub Narebski
2010-05-11 12:09 ` Peter Vereshagin
2010-05-11 13:51 ` Jakub Narebski [this message]
2010-05-13 13:10 ` Peter Vereshagin
2010-05-13 17:13 ` Ævar Arnfjörð Bjarmason
2010-05-14 15:58 ` Peter Vereshagin
2010-05-14 10:53 ` Jakub Narebski
2010-05-14 15:36 ` Peter Vereshagin
2010-05-14 17:58 ` Jakub Narebski
2010-05-14 18:43 ` Jakub Narebski
2010-05-15 10:06 ` Peter Vereshagin
2010-05-15 13:58 ` Jakub Narebski
2010-05-16 10:15 ` Peter Vereshagin
2010-05-18 1:06 ` Jakub Narebski
2010-05-16 10:26 ` Petr Baudis
2010-05-15 11:51 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201005111551.21316.jnareb@gmail.com \
--to=jnareb@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jgoerzen@complete$(echo .)org \
--cc=juanjo@comellas$(echo .)org \
--cc=normalperson@yhbt$(echo .)net \
--cc=pasky@suse$(echo .)cz \
--cc=peter@vereshagin$(echo .)org \
--cc=sam.vilain@catalyst$(echo .)net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox