On 11/14/2012 03:53 PM, André Warnier wrote:
> The tidbit above makes me think about a possibility to solve another
> issue that happens from time to time : some users browsers that are NOT
> refreshing their copies of stylesheets or javascript libraries, even
> though they have been modified.
> No
Torsten Förtsch wrote:
On 11/14/2012 02:48 PM, André Warnier wrote:
I my particular case, the sendfile() solution above works fine, because
I am sure in this case that no additional processing needs to take place
on those static pages.
What I meant in particular was the HTTP code 304 generatio
On 11/14/2012 02:48 PM, André Warnier wrote:
> I my particular case, the sendfile() solution above works fine, because
> I am sure in this case that no additional processing needs to take place
> on those static pages.
What I meant in particular was the HTTP code 304 generation. With your
solution
Torsten Förtsch wrote:
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 :
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
Sure thing, anytime.
You raise valid points and are in the best position to know what kind of
tradeoffs to make. Simpler handler requires less processing and memory
but increased number of requests.
I said what I did because I'm working on a single page app. with heavy
use of Javascript (Go
Torsten Förtsch wrote:
On 11/12/2012 06:19 PM, André Warnier wrote:
In response to some request URLs, I have to compose a response
structured as follows :
- a html frameset document with two frames
- in the 1st frame, the result of another HTTP request to the same
Apache server.
This URI of t
On 11/12/2012 06:19 PM, André Warnier wrote:
> In response to some request URLs, I have to compose a response
> structured as follows :
>
> - a html frameset document with two frames
> - in the 1st frame, the result of another HTTP request to the same
> Apache server.
> This URI of this HTTP req
Hi.
Once again, thanks. Your javascript/onLoad idea sounds good, and would fit my
needs.
I'll give it a spin.
There is one thing that bothers me (and it is the same in my own solution outlined below)
: what previously was one HTTP request and one response, now becomes 3 HTTP requests and 3
r
Hi.
Thank you for your response.
You are not missing the point of my questions.
But I do not really have control over the requests. Or rather, I do, but there are
hundreds of pages containing hundreds of similar (but not equal) links, and it is in the
practice not doable to edit them all..
And
Q1: At first glance, using a mod_perl handler to serve an existing
static html file seems like overkill.
Couldn't Apache respond (RedirectMatch?) with a common frameset html
file with some Javascript, which then fills the first frame with the
response to mangle.pl and the second frame with t
Hi.
context: Apache2.x, mod_perl 2.x
In response to some request URLs, I have to compose a response structured as
follows :
- a html frameset document with two frames
- in the 1st frame, the result of another HTTP request to the same Apache
server.
This URI of this HTTP request is created b
g at the explanations for sub-requests, lookup_uri etc.., I get
> the impression however that calling these, pretty much terminates the
> current request, and replaces it by the one I'm calling.
> Which is not what I want.
> I want to continue processing the current request but usin
t the content, before I go on with my current
request.
But I figure there must be an easier and more efficient way, no ?
Looking at the explanations for sub-requests, lookup_uri etc.., I get
the impression however that calling these, pretty much terminates the
current request, and replaces
Torsten Foertsch wrote:
[...]
And I don't think that Apache will skip the mod_perl AAA phases, will
it ?
Yes, mod_perl handlers are called inside these ap_run_... functions.
ap_run_access_checker() is the first of the 3 A's. A PerlAccessHandler
is called from this function.
Thanks again fo
On Sun 12 Oct 2008, André Warnier wrote:
> I have a little question related to the above, but not very urgent :
> why the check on the configuration change ? what can change between a
> request and a sub-request (or internal redirect) ?
Suppose this:
Require group foo
Require group bar
If d
Adam Prime wrote:
http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_internal_redirect_
Thanks.
Although considering Torsten previous answer and explanation, that's
kind of an odd place, no ? ;-)
[...]
It seems odd to me to set $r->user in an AccessHandler. It's probably
not
André Warnier wrote:
Torsten,
Many thanks for the excellent information, I will ponder that.
More below, but one more question here :
Where does $r->internal_redirect "live" (in which package) ?
I am having trouble finding it.
http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_inte
Torsten,
Many thanks for the excellent information, I will ponder that.
More below, but one more question here :
Where does $r->internal_redirect "live" (in which package) ?
I am having trouble finding it.
Torsten Foertsch wrote:
On Sun 12 Oct 2008, André Warnier wrote:
In an attempt at being
On Sun 12 Oct 2008, André Warnier wrote:
> In an attempt at being clever, I put the following code in the
> handler :
>
> unless ($r->is_initial_req) {
> if (defined $r->prev) {
> # we are in a subrequest. Just copy user from main
> request. $r->user( $r->prev->user );
>
Hi.
I am writing a new PerlAuthHandler module.
It is working fine in most cases, but..
In an attempt at being clever, I put the following code in the handler :
unless ($r->is_initial_req) {
if (defined $r->prev) {
# we are in a subrequest. Just copy user from main reque
Anthony Gardner <[EMAIL PROTECTED]> writes:
> Okay, including the new query string in the lookup_uri now correctly
> populates the QUERY_STRING in the sub request but
> that isn;t the answer to my problems.
>
> Within the called script, we make a call to $cgi->Vars but this is
> returning the que
Cool. you're a diamond.
stay tuned for the next problem!!
Perrin Harkins <[EMAIL PROTECTED]> wrote: On 3/30/07, Anthony Gardner wrote:
> One more question, I had to put the data in notes so that it was available
> in the inital script. Is that the right way to do it?
That's a good way to do it.
On 3/30/07, Anthony Gardner <[EMAIL PROTECTED]> wrote:
One more question, I had to put the data in notes so that it was available
in the inital script. Is that the right way to do it?
That's a good way to do it. I think the alternative is to rig some
kind of filter to capture the output of the
Ookay. Had a play with initalising the globals and got the thing
working.
One more question, I had to put the data in notes so that it was available in
the inital script. Is that the right way to do it?
Perrin, thanks for all your help on this. I've learnt a lot more, too which is
als
On 3/30/07, Anthony Gardner <[EMAIL PROTECTED]> wrote:
Within the called script, we make a call to $cgi->Vars but this is returning
the query string from the initial request.
That's just a problem with the way CGI.pm is coded. It essentially
doesn't work for subrequests or internal redirects b
Okay, including the new query string in the lookup_uri now correctly populates
the QUERY_STRING in the sub request but that isn;t the answer to my problems.
Within the called script, we make a call to $cgi->Vars but this is returning
the query string from the initial request. Is it taking that f
Yeah, you know what, I was mistakingly using lookup_file for ages and then
changed to lookup_uri but then overlooked the possibilty of adding on the
qsuery string.
Ho hum, will try tomorrow. Am getting there slowly.
Perrin Harkins <[EMAIL PROTECTED]> wrote: On 3/29/07, Anthony Gardner wrote:
>
On 3/29/07, Anthony Gardner <[EMAIL PROTECTED]> wrote:
I can use PassEnv and PerlPassEnv, set them in the calling script and then
retrieve the values in the called script (sub request) cool!!
You could also put things in $r->pnotes(). The parent request object
is available from within
All, I've now had a chance to look at implementing sub requests and it seems to
be the thing I need but .
I need some more info that I've been unable to get from the book or the web.
To begin with, the environment passed to the sub request has to be managed and
I've
On Thursday 06 October 2005 19:51, Torsten Foertsch wrote:
> is there a way to hand POST input over to a sub-request?
OK, C<< $subr->method( $r->method ) >> did it.
pgp1OkyOBHd1W.pgp
Description: PGP signature
Hi,
is there a way to hand POST input over to a sub-request?
Thanks,
Torsten
pgpGn77FeCg7I.pgp
Description: PGP signature
32 matches
Mail list logo
