Hi everyone,
I have a problem and I can't figure a solution, so I'm asking here, hoping
not to bother.
I have a perl script that takes a FILEPATH and should redirect to the
FILEPATH on the server. Everything works fine in my setup with the help of a
$r-handler(Apache2::Const::DIR_MAGIC_TYPE) in
On Friday 07 May 2010 12:44:54 Cédric Bertolini wrote:
So my question is : how can I respond with a 301 or 307 Redirect to the
client?
$r-err_headers_out-{Location}='http://...';
return 301; # or 302 or 303 or 307
Torsten Förtsch
--
Need professional modperl support? Hire me!
On Thursday 18 March 2010 21:59:26 E R wrote:
To serve the file the CGI script issues an internal redirect to a url
which points to the cached results.
My question is: can the url which points to the cached results be
protected so that it cannot be directly accessed by external clients?
Thanks for all of the suggestions. Looking for REDIRECT_* environment
variables seems like it will work for me.
2010/3/19 Torsten Förtsch torsten.foert...@gmx.net:
On Thursday 18 March 2010 21:59:26 E R wrote:
To serve the file the CGI script issues an internal redirect to a url
which points
Hi all,
This is not exactly a mod_perl question - in fact I hope there is a
solution which does not use mod_perl.
I have a CGI script which generates a lot of output. Because it takes
a lot of time to the output, the results are cached in case the same
request is made again.
To serve the file
On 03/18/2010 04:59 PM, E R wrote:
My question is: can the url which points to the cached results be
protected so that it cannot be directly accessed by external clients?
You should be able to do something like this for that Location block
(so you might have to put that URL inside of a
Rather than doing the URL redirect, why not just keep the cached results
in a private directory, and let the CGI open them and serve them up
directly? This would be the most secure way.
So, you could do something like this:
On 03/18/2010 06:05 PM, Michael A. Capone wrote:
This would be the most secure way.
Saying it's the *most* secure way is a little stretch. It's *another*
secure way. Also, keeping a large Perl/CGI process alive just to serve a
static file is a waste. In fact, if you can think of a
Both very good points! I stand corrected.
Michael Peters wrote:
On 03/18/2010 06:05 PM, Michael A. Capone wrote:
This would be the most secure way.
Saying it's the *most* secure way is a little stretch. It's *another*
secure way. Also, keeping a large Perl/CGI process alive just to serve
Hi
I am trying to use:
$headers = $r-headers_out;
$r-no_cache(1);
$headers-set( Location = url );
return REDIRECT.
The first problem is this does not set the Cache-Control header.
If instead of the redirect I output some content (200 ) then it does, correctly.
Is there some reason why this
Justin Wyllie wrote:
Hi
I am trying to use:
$headers = $r-headers_out;
$r-no_cache(1);
$headers-set( Location = url );
return REDIRECT.
The first problem is this does not set the Cache-Control header.
If instead of the redirect I output some content (200 ) then it does,
correctly.
Justin Wyllie wrote:
I am trying to use:
$headers = $r-headers_out;
$r-no_cache(1);
$headers-set( Location = url );
return REDIRECT.
You didn't specify your Apache/mod_perl version. For 2.x this is what I have
and it works fine:
$r-no_cache(1);
On Wed, 31 Dec 2008, Foo JH wrote:
Mark Hedges wrote:
http://search.cpan.org/~markle/Apache2-Controller-1.000.001/
Very interesting. I have a controller which functions in a
slightly different way, but it's good to see alternative
approaches. I think yours makes life easier.
Thanks Foo!
Mark Hedges wrote:
- a lot of times people use references to
other structures when they should subclass... these
references function only to re-map arguments to other
modules, which is ridiculous.
Careful on the should. It can seem extra and possibly confusing but
isn't always. Delegation
Oh no, the framework doesn't depend on using a session
at all. Just this particular auth module depends on
plugging in the session beforehand.
So I have to have a persistant backstoring session in
order to use the auth module?
Well, now, but as you recommended, maybe not necessary.
there, and then they come back to
# openid-check.app, then you see what the identity server said;
Is that module supposed to work some other way than
with redirects?
I thought the point was that they log into the OpenID server
and bounce back to my app. That way they never have to
trust my app
understand once
you nav away from a page through a whole-page submit, its state is (well
can be) gone for good. You're in a linear sequence of redirects at that
point and if for some reason you're not authenticated, you're not going
to regain the state.
Why does the consumer
object return a check url
stuff.
PUT to get redispatched to a GET request for an HTML
login form.
Heh, you have a point there. I'd be more interested in
getting an error response telling me that something had to
be done than in getting willy-nilly redirects that violate
the communication protocol established. if I'm
Mark Hedges wrote:
On Tue, 30 Dec 2008, David Ihnen wrote:
in the meantime server 556 dublin suffered a network
connector air gap issue. A trouble ticket has been
created. These things happen.
client - GET success bounceback url - load balancer -
server 22 london - looks up saved
Mark Hedges wrote:
[...]
Hi.
Not to discourage you, but to point out some additional aspects..
There is a Belgian proverb that says essentially one should not try to
be more catholic than the pope.
What I mean by that is that there are many twists to web authentication,
and it is really
Mark Hedges wrote:
The question is, since the handler doing the preservation
and installing the input filter also instantiates an
Apache2::Request object, when it gets to the response phase
controller, will the response handler's Apache2::Request
instance read the replaced data or the cached
On Mon, 29 Dec 2008, David Ihnen wrote:
Say the application's session times out, but the user
posts something by clicking submit.
They are redirected to the OpenID server but it says
they are still logged in and returns a positive
response.
But you can't know that they are
target iframe
- iframe redirects for auth
- iframe gets auth
- success page activates parent re-submit
- submit form target iframe
- iframe success activates main page success state
Though that is, of course, specific to the application being programmed,
utilizing client-side javascript active
On Mon, 29 Dec 2008, David Ihnen wrote:
Though that is, of course, specific to the application
being programmed, utilizing client-side javascript active
stuff rather than particular web server programming to
transparently handle it on the server side using basic
html2.0 type structure.
I
Mark Hedges wrote:
On Mon, 29 Dec 2008, David Ihnen wrote:
Though that is, of course, specific to the application
being programmed, utilizing client-side javascript active
stuff rather than particular web server programming to
transparently handle it on the server side using basic
html2.0
On Sat, 27 Dec 2008, Mark Hedges wrote:
Hi, I'm trying to figure out how to preserve the request
body across an OpenID login redirect cycle.
...
But when they come back from the OpenID server, how do I put
the saved request body or post params into the new request?
Aha, I didn't quite get
On Sun, Dec 28, 2008 at 12:08 AM, Mark Hedges hed...@scriptdolphin.org wrote:
On Sat, 27 Dec 2008, Mark Hedges wrote:
Hi, I'm trying to figure out how to preserve the request
body across an OpenID login redirect cycle.
...
But when they come back from the OpenID server, how do I put
the
Fred Moyer wrote:
On Sun, Dec 28, 2008 at 12:08 AM, Mark Hedges hed...@scriptdolphin.org wrote:
On Sat, 27 Dec 2008, Mark Hedges wrote:
Hi, I'm trying to figure out how to preserve the request
body across an OpenID login redirect cycle.
...
But when they come back from the OpenID server, how
and
should not have to re-send the original request. Magic.
So it's looking like this:
- user logs in, does stuff, goes to get coffee
- user comes back, clicks 'submit' on whatever form
- session is idle:
- reads and stores raw request body from bb's
- saves the method number
- redirects
Hi, I'm trying to figure out how to preserve the request
body across an OpenID login redirect cycle.
This handler is running as a PerlHeaderParserHandler.
Say the application's session times out, but the user posts
something by clicking submit.
They are redirected to the OpenID server but it
Hi,
I'm trying to figure out if anything ever happened with this bug where
internal redirects cause method handlers to get called as subs.
http://marc.info/?l=apache-modperl-devm=101261915419106w=2
http://marc.info/?l=apache-modperlm=106839932418976w=2
The thread ends without a fix and I don't
Will Fould wrote:
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Oddly enough, I simply placed a few warn('blah') code snippets to
crudely determine from the error log where it was happening in
production
On Tue, 2007-01-16 at 16:45 -0800, Will Fould wrote:
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Are you saying that you don't have any code in the script that generates
redirects, but they sometimes happen
Assuming your not re-using session variables, you might want to verify that
your package names do not conflict and that your conditions for any redirects
are not confused. I remember fighting this in a previous life.
B
On Wednesday 17 January 2007 08:24, Perrin Harkins wrote:
On Tue, 2007-01
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Oddly enough, I simply placed a few warn('blah') code snippets to crudely
determine from the error log where it was happening in production (because I
cannot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jan 16, 2007 at 04:45:10PM -0800, Will Fould wrote:
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Oddly enough, I simply placed a few warn('blah')
Dear mod_perl types,
A system I have installed relies on doing redirects like the code below, but
the redirects don't happen, I just get blank pages in the browser.
I have tested temp redirects in httpd.conf and they work fine.
Can anyone tell me if the code below should work
Ian Grant wrote:
Dear mod_perl types,
A system I have installed relies on doing redirects like the code below, but
the redirects don't happen, I just get blank pages in the browser.
I have tested temp redirects in httpd.conf and they work fine.
Can anyone tell me if the code below
On Jan 3, 2007, at 11:24 AM, Geoffrey Young wrote:
my $request=Apache2::RequestUtil-request();
my $url='https://www.some.place.ac.uk/perl/newscript';
$request-headers_out-{'Location'} = $url;
$request-status_line(302 Moved);
Personally, I do this:
Jonathan Vanasco wrote:
$self-{'ApacheRequest'}-status(Apache2::Const::REDIRECT);
Don't do that. That's an internal apache code, not an HTTP code. The
HTTP code would be something like Apache2::Const::HTTP_MOVED_TEMPORARILY.
return Apache2::Const::REDIRECT;
That's the only
Perrin Harkins wrote:
Jonathan Vanasco wrote:
$self-{'ApacheRequest'}-status(Apache2::Const::REDIRECT);
Don't do that. That's an internal apache code, not an HTTP code. The
HTTP code would be something like Apache2::Const::HTTP_MOVED_TEMPORARILY.
actually, REDIRECT is an alias
Geoffrey Young wrote:
actually, REDIRECT is an alias for HTTP_MOVED_TEMPORARILY. from
modperl_constants.c:
if (strEQ(name, REDIRECT)) {
return newSViv(HTTP_MOVED_TEMPORARILY);
}
Isn't that basically a coincidence though? I thought the non-HTTP
constants were subject to change at
Perrin Harkins wrote:
Geoffrey Young wrote:
actually, REDIRECT is an alias for HTTP_MOVED_TEMPORARILY. from
modperl_constants.c:
if (strEQ(name, REDIRECT)) {
return newSViv(HTTP_MOVED_TEMPORARILY);
}
Isn't that basically a coincidence though? I thought the non-HTTP
constants
I have a application with mod_perl Authen/Authz handlers that will
redirect to a login screen (via ErrorDocument) if the user is not logged
in. Users follow links in emails and these links occasionally have
anchors in them:
http://mysite.com/app?foo=bar#123
For the ErrorDocument 403 page that
On Fri, 21 Apr 2006 11:49:19 -0400
Michael Peters [EMAIL PROTECTED] wrote:
I have a application with mod_perl Authen/Authz handlers that will
redirect to a login screen (via ErrorDocument) if the user is not
logged in. Users follow links in emails and these links occasionally
have anchors in
Frank Wiles wrote:
On Fri, 21 Apr 2006 11:49:19 -0400
Michael Peters [EMAIL PROTECTED] wrote:
I have a application with mod_perl Authen/Authz handlers that will
redirect to a login screen (via ErrorDocument) if the user is not
logged in. Users follow links in emails and these links
Michael Peters wrote:
Frank Wiles wrote:
[...]
Which works fine except that the anchor info (#123) is lost. Is there
anyway to get this from the original request's URL?
I think you're looking for $r-prev-unparsed_uri
Thanks, but I guess I should have mentioned that I'm using mod_perl 1
On Fri, 21 Apr 2006 9:31 am, Fred Moyer wrote:
Michael Peters wrote:
Frank Wiles wrote:
[...]
Which works fine except that the anchor info (#123) is lost. Is there
anyway to get this from the original request's URL?
The 2.0 docs seem to indicate that this piece is called the 'fragment'
Fred Moyer wrote:
On Fri, 21 Apr 2006 9:31 am, Fred Moyer wrote:
Michael Peters wrote:
Frank Wiles wrote:
[...]
Which works fine except that the anchor info (#123) is lost. Is there
anyway to get this from the original request's URL?
The 2.0 docs seem to indicate that this piece is
fragment() is also discussed in chapter 5 of the mpdc. it's been a while,
but I'm pretty sure that what it says in 5.3 is true, that the browser holds
on to it (as it does auth information) and won't let the server know.
Yeah, it's oddly hard to find references to this. The best I found was:
David Wright wrote:
fragment() is also discussed in chapter 5 of the mpdc. it's been a
while,
but I'm pretty sure that what it says in 5.3 is true, that the browser
holds
on to it (as it does auth information) and won't let the server know.
Yeah, it's oddly hard to find references to
That's what I just found out too. I tried Fred's suggestions of using
Apache::URI's fragment, but nothing seemed to work. So I decided to just
make sure it was being passed to the server. It seems that the browser
(tried with FF 1.5 and wget) doesn't pass the #fragment.
If this is true,
On Wed, 2005-04-13 at 14:05 -0400, Jonathan Vanasco wrote:
How do people usually handle searches and redirects?
IE - someone searches for something, you process the search, and if
there's one record, you redirect them to that record.
Except, in that situation, the browser 'location
53 matches
Mail list logo
