On 11/13/2012 07:17 PM, André Warnier wrote:
I didn't want to take too much time of anyone before, which is why I
somewhat oversimplified the issue. But considering the traffic on the
lis os low, maybe you want to hear the whole story after all.
The basic case is this : a bit aside from our usual professional
activities and for a friend, we run a website which is basically a shop
with hundreds of individual items which people can view and buy. (I
will provide the URL privately to anyone who is more interested. It's a
cute shop.)
The pages corresponding to these individual items, at the moment, are
individual static pages in multiple sub-directories, and there are quite
a lot of them. The friend creates and maintains these static pages
herself; she is an artist rather than a programmer, so she can handle an
html editor (which she does rather well) to edit static pages and test
them on her PC before copying them to the server, but we cannot ask her
to handle any kind of "template" pages or the like.
Add to this that the basic logic of the website and the design and
techniques used date back from some 10 years ago, have been patched and
repatched several times over several years, and are rather bad.
Now there is a requirement that, instead of being just static pages,
each of these pages should in addition contain a <form> with some
specific item-related information, allowing to buy these items on-line
(so it cannot be done just with an include or a stylesheet).
Have you considered to patch the files automatically? CPAN has a bunch
of modules that can parse also quite bad/old HTML (with missing </p> or
</li> and the stuff).
You could for example keep the original files in one directory tree and
set up a process that waits for changes there either by scanning it on a
regular basis or even by using inotify (there is a cron-like daemon that
is made just for this kind of monitoring. I think it's called incron or
so. Anyway, there is plenty of support for inotify on CPAN.)
Now, if anything changes the daemon can start a program that parses the
HTML, inserts the form and writes the result to another directory which
is your DocumentRoot. On the way it could also call 'git commit'. And
now you have a simple content management system almost for free.
What I am trying to achieve, without having to edit each of these
individual hundreds of pages, or changing the links to these pages, or
change the basic design of the application (because there is no budget
for that), is to find a clever way on the server side
to respond to a normal "/Shop_xxx/def/xyz.html" URL of one of these
pages, to combine into one response both the required <form>, and the
content of the existing unmodified static page. I also do not want to
parse the html on-the-fly and insert a <form> right into it, because the
html that she creates with her (T-online) editor is rather bad to start
with, and I have no guarantee that the result would be pleasing.
So that was the reason to think of the <frameset> solution, whereby in
response to the initial request for "/Shop_xxx/def/xyz.html", I would
respond with a first <frame> containing the form (generated by a
back-end application, and depending on the item), and a second <frame>
containing her artfully-crafted static page describing that item in all
its glory.
The static pages in question are in several subdirectories of
DocumentRoot, and at different levels. Fortunately, all the top
sub-directories names start with "/Shop_" (after which there can be
"Quilts" or "Babydecken" and things like that, and a variable hierarchy
of sub-directories containing html files and jpg images and the like.
So I have this configured :
<LocationMatch "^/Shop_">
sethandler modperl
PerlResponseHandler My::ShopResponse
...
</LocationMatch>
As a result in part of the previous communications on this list, this
PerlResponseHandler
does more or less what I want, except one remaining problem which I am
trying to resolve right now :
In response to an initial request for "/Shop_xxx/def/xyz.html", the
handler generates a
<frameset> document as such :
<html>
<frameset rows="100,*">
<frame name="top_frame" src="..the URI which generates the form.." />
(1)
<frame name="bottom_frame" src="/Shop_xxx/def/xyz.html.shop" /> (2)
</frameset>
</html>
(1) for the dynamically-generated html <form> document
(2) for the static existing page
Because the second frame's URI also starts with "/Shop_", when the
browser requests this frame, the same ResponseHandler is called.
The handler examines the URL and sees that it ends in ".shop" (instead
of ".html").
So it knows that this time, it should not send another frameset, but
instead it should strip the trailing ".shop" and deliver, as is, the
content of the static document "/Shop_xxx/def/xyz.html".
But, how do I tell it to do that ?
I have tried :
my $uri = $r->uri();
if ($uri =~ m!\/([^/]+\.htm[l]?\.shop)$!i) {
$uri =~ s/\.shop$//; # strip the trailing ".shop"
$r->internal_redirect($uri);
return Apache2::Const::OK ;
}
and also :
my $uri = $r->uri();
if ($uri =~ m!\/([^/]+\.htm[l]?\.shop)$!i) {
$uri =~ s/\.shop$//; # strip the trailing ".shop"
my $subr = $r->lookup_uri($uri);
$subr->run();
return Apache2::Const::OK ;
}
but both of those result in a loop : they end up requesting
"/Shop_xxx/def/xyz.html", which hits the same Location, which runs the
same handler, which then produces the frameset, and so on.
Here is how the cycle goes:
1) The server gets a request for /Shop_xxx/def/xyz.html, skips the
if-branch and generates the frameset.
2) The bottom frame generates another request for
/Shop_xxx/def/xyz.html.shop. It enters the if-branch and issues a
subrequest or an internal redirect for /Shop_xxx/def/xyz.html.
3) The subeq/redir enters the handler again. Now it avoids the if-branch
because it does not match /\.shop$/. So it spits out the frameset.
4) goto 2) by means of the browser
How to break the loop? Instead (or inside) of the LocationMatch above use:
PerlFixupHandler "sub { \
use Apache2::RequestUtil (); \
use Apache2::RequestRec (); \
use Apache2::Const -compile=>qw/DECLINE/; \
my ($r)=@_; \
if( $r->is_initial_req ) { \
$r->handler('modperl'); \
$r->set_handlers(PerlResponseHandler=>'My::ShopResponse'); \
} \
return Apache2::Const::DECLINED; \
}"
Then step 3) reads:
3) The subreq/redir enters the request cycle again. The if-branch of
fixup handler is skipped because the request is not initial. Hence, the
PerlResponseHandler is skipped completely and the default handler sends
the document.
You can achieve a similar effect with mod_rewrite. It has IS_SUBREQ
available in RewriteCond. But I don't know if that also checks for
!$r->prev.
You can also try to modify your Response handler to decline if
!$r->is_initial_req:
my $uri = $r->uri();
if ($uri =~ s!(/[^/]+\.html?)\.shop$!$1!i) {
$r->internal_redirect($uri);
return Apache2::Const::OK ;
}
return Apache2::Const::DECLINE unless $r->is_initial_req;
I am not sure if that works. I think I have never tried to return
DECLINED from a response handler.
So how do I tell Apache/mod_perl that this time "I mean it", and that it
should directly deliver the requested file, without re-running the whole
cycle ?
I can of course request the corresponding filename() and deliver it
myself (perhaps with sendfile()), but that does not seem to be the most
elegant way of doing this. Or is it ?
Oh, and I'd like it elegant, but I would prefer not having to introduce
a PerlFixupHandler or a PerlOutputFilter or Javascript, and do it all
within this ResponseHandler. That's because I have colleagues who know
even less about mod_perl than I do, and I'd like to leave them something
simple to deal with in support and maintenance for another 10 years.
...
Aside : I just tried
my $uri = $r->uri();
if ($uri =~ m!\/([^/]+\.htm[l]?\.shop)$!i) {
$uri =~ s/\.shop$//; # strip the trailing ".shop"
my $subr = $r->lookup_uri($uri);
$r->sendfile($subr->filename());
return Apache2::Const::OK ;
}
and that works. So I guess that /is/ the right solution here.
No, it's not.
The default handler does a bit more than just send $r->filename. For you
it may work but it won't in the general case. See default_handler() in
server/core.c.
Torsten
