On Fri, Sep 05, 2003 at 10:13:36, Geoffrey Young said...
actually, the return value is entirely ignored in Registry scripts - that's
why we need the $r-status hack, which is not needed (or desired) in
handlers. if you returned SERVER_ERROR it would still work, so long as you
set $r-status
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie
Michael wrote:
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie
Title: FW: $r-headers_out Location and Set-Cookie
[Note: reposting, the original post appears to have dropped through the cracks]
Geoffrey Young wrote:
That's when you use Apache::compat, doing the mp1 syntax.
In mp2-speak that would be:
$r-err_headers_out-add('Set-Cookie
Garrett Goebel wrote:
[Note: reposting, the original post appears to have dropped through the
cracks]
not only did I get two of these already, but I also posted a reply :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Title: RE: FW: $r-headers_out Location and Set-Cookie
Geoffrey Young wrote:
Garrett Goebel wrote:
[Note: reposting, the original post appears to have dropped
through the cracks]
not only did I get two of these already, but I also posted a reply :)
My bad. It was an old thread and I
Title: RE: $r-headers_out Location and Set-Cookie
Geoffrey Young wrote:
That's when you use Apache::compat, doing the mp1 syntax.
In mp2-speak that would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT
Garrett Goebel wrote:
Geoffrey Young wrote:
That's when you use Apache::compat, doing the mp1 syntax.
In mp2-speak that would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT);
notice that you don't
gerard uolaquetalestem [EMAIL PROTECTED] writes:
[...]
But exactly what's the difference between err_headers_out and
headers_out? I understand that the first is related with an error message
sended by headers, but i mean, really what does apache make different?
Here's a straightforward
Chris Faust wrote:
I haven't had any problems setting a cookie and redirecting on MP2 by using
the below
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-header_out('Location' = $url);
$r-status(REDIRECT);
$r-send_http_header;
That's when you use Apache::compat, doing the mp1
Hi All,
Any idea if Set-Cookie2: is going to be implemented in CGI.pm? Lincohn?
Regards,
Jie
$r-headers_out-{'Set-Cookie'} = $cookie;
$r-headers_out-{'Location'} = $url;
Redirects the page to $url but cookie is not seen by browser
$r-headers_out-{'Set-Cookie'} = $cookie;
#$r-headers_out-{'Location'} = $url;
Location is the perl handler 'localhost/pageB/' (perl handler), if you then go
,
and
after to redirect to the same page A who is ready to catch the cookie.
Yep. You need $r-err_headers_out-{'Location'} and you could change
to $r-err_headers_out-{'Set-Cookie'} too.
Even that doesn't work. You need to do a Refresh, because that's the
only way the browser will register the cookie - Set
Hi, I've seen that the key is the status returned to apache.
With Apache::REDIRECT i have the next code works ok
$apache-err_headers_out-{'Set-Cookie'} = $value1;
$apache-err_headers_out-{'Location'} = $value2;
But exactly what's the difference between err_headers_out and
headers_out? I
don't have the cookie
posted, but if i comment the Location header, then i stay at perl handler
location, and if i go manually to page A then i see that the cookie is posted.
So why these two headers doesn't respect themselves?
Resuming
$r-headers_out-{'Set-Cookie'} = $cookie;
$r-headers_out
Jie Gao wrote:
Hi All,
Any idea if Set-Cookie2: is going to be implemented in CGI.pm? Lincohn?
Jie, AFAIK, this has nothing to do with mod_perl. See:
http://stein.cshl.org/WWW/software/CGI/#bugs
__
Stas BekmanJAm_pH
I haven't had any problems setting a cookie and redirecting on MP2 by using
the below
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-header_out('Location' = $url);
$r-status(REDIRECT);
$r-send_http_header;
-Chris
- Original Message -
From: gerard uolaquetalestem
That's when you use Apache::compat, doing the mp1 syntax. In mp2-speak
that would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT);
notice that you don't need to call $r-send_http_header, it doesn't
exist in mp2
already exist, fetch some results from a
database, put the results in the session, then redirect to another page
that is responsible for pulling the results out of the session and
producing the html output. As a test case, I do exactly this:
$r-header_out(Set-Cookie = 'foo1=bar1');
$r
Use err_header_out() when response status is other than 200.
$r-err_header_out(Set-Cookie = 'foo1=bar1');
Regards,
Tim Tompkins
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
to another page
that is responsible for pulling the results out of the session and
producing the html output. As a test case, I do exactly this:
$r-header_out(Set-Cookie = 'foo1=bar1');
$r-header_out(Location = $redir);
return REDIRECT;
I use curl to test with - the result does
variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie
without path attribute.
I think, it's a good idea to make WhatEverPath required option in
config.
Hrm. I was not aware of that. Thanks for bringing it to my attention.
I have changed AuthCookie in CVS so that Path
Location /agenda/
SetHandler perl-script
PerlHandler Apache::Agenda
PerlSetVar AgendaPath /agenda
PerlSetVar AgendaTemplate default.inc
PerlSetVar AgendaSessionDir /tmp
PerlSetVar AgendaLoginScript /agenda/login/
Are you sure that last line is
/Location
Problem was here - AgendaPath variable is set in /agenda.* location
/LOGIN/ script, which set session key cookie header, doesn't see
AgendaPath, therefore Cookie was a
Apache::AuthCookieAgenda_Agenda=login:password
variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie
without
Skipped
Actually, as my application should be
1. simple maintained,
2. maximum count of users - 100 (employees in small software
development company)
3. simultaneous login - 5-7 maximum
4. team managers work with money (project budjet, employee's payment
per hour and etc)
5. good session
2002] [error] credential_1 asdasd
[Mon Jan 28 12:38:35 2002] [error] ses_key asdasd:asdasd
OUT Headers goes here
$VAR1 = 'Pragma';
$VAR2 = 'no-cache';
$VAR3 = 'Cache-control';
$VAR4 = 'no-cache';
$VAR5 = 'Location';
$VAR6 = '/agenda/tasks/';
Error OUT Headers goes here
$VAR1 = 'Set-Cookie
';
$VAR6 = '/agenda/tasks/';
Error OUT Headers goes here
$VAR1 = 'Set-Cookie';
$VAR2 = 'Apache::AuthCookieAgenda_Agenda=asdasd:asdasd';
$VAR3 = 'Pragma';
$VAR4 = 'no-cache';
Redirecting...
and next phase
[Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
[Mon Jan 28 12
of lookup on the server-side for every request
if they need session information. It may not be to a database though. If
you know that each user will stay on a single server, you can use a
disk-based technique like Cache::FileCache or Apache::Session::File.
Apache::AuthCookie doesn't want to set cookie
On Wed, Jun 27, 2001 at 10:59:16AM -0700, Rob Bloodgood wrote:
me, on the other hand, i don't see the problem with
on incoming request
if has-cookie 'session'
{
update serverside 'accesstime' for session[this] to NOW
On Mon, Jun 25, 2001 at 04:54:59PM -0700, Rob Bloodgood wrote:
maybe storing 'last-access-time' on the server, instead of in
the client-side, via cookie, would solve this snafu?
But if you want to give out a new cookie on every request ?
How would you prevent them from copying or
me, on the other hand, i don't see the problem with
on incoming request
if has-cookie 'session'
{
update serverside 'accesstime' for session[this] to NOW
Oh yeah? HOW???
if not-modified-since
On Fri, Jun 22, 2001 at 12:32:28PM -0700, Doug MacEachern wrote:
quoting his email:
The cookie records, in part, the time of the last access to
the site. Therefore for each access the cookie is updated.
that to me sounds like a header which may have changed independently of
the
will trillich wrote:
On Fri, Jun 22, 2001 at 12:32:28PM -0700, Doug MacEachern wrote:
quoting his email:
The cookie records, in part, the time of the last access to
the site. Therefore for each access the cookie is updated.
that to me sounds like a header which may have changed
maybe storing 'last-access-time' on the server, instead of in
the client-side, via cookie, would solve this snafu?
But if you want to give out a new cookie on every request ?
How would you prevent them from copying or tampering with the contents?
a MD5-hash would stop them from changing
. Schwartz wrote:
Doug == Doug MacEachern [EMAIL PROTECTED] writes:
Doug i passed it along the same day:
Doug http://hypermail.linklord.com/new-httpd/2001/Jun/0507.html
Doug still awaiting response on my interpretation of the rfc, seems perfectly
Doug valid to include the set-cookie header
a typical request
Date: Tue, 19 Jun 2001 01:03:02 GMT
Server: Apache/1.3.20 (Unix) mod_perl/1.25
Set-Cookie:
session=69643d343037266c6173746163636573733d393932393132353933; path=/
Last-Modified: Mon, 18 Jun 2001 17:09:26 GMT
ETag: 25c4f-6-3b2e35c6
Accept-Ranges: bytes
Content-Length: 6
Connection: close
On 21 Jun 2001, Randal L. Schwartz wrote:
Uh, it seems a bit fishy to me. nothing's changed, but by the way,
set this cookie please. Why change a cookie if nothing else has
changed?
don't gimme this 'fishy' mumbo jumbo, i'm willing to accept a valid reason
why set-cookie shouldn't
Hello,
DMi'm willing to accept a valid reason why set-cookie shouldn't be
DMincluded in a 304 response, but i have yet to hear one.
For the record, I agree, and I agree that mod_perl should allow this.
From a practical point of view, though, I've tended to avoid this
situation altogether
still awaiting response on my interpretation of the rfc, seems perfectly
valid to include the set-cookie header with a 304 response.
you could of course delete the if-modified-since header from headers_in,
but that would put an end to caching of those documents, something i'm
sure nobody wants
Doug == Doug MacEachern [EMAIL PROTECTED] writes:
Doug i passed it along the same day:
Doug http://hypermail.linklord.com/new-httpd/2001/Jun/0507.html
Doug still awaiting response on my interpretation of the rfc, seems perfectly
Doug valid to include the set-cookie header with a 304 response
that the file-date has changed.
(i am not quite confortable with patching every new apache version again,
or would it be a good idea to send this to the apache-guys ?)
Thanks again,
Nenad
Andrew Gilmartin wrote:
How can I force Apache to send the Set-Cookie header even if the
document being
changed.
Unfortunately, if it has not changed the cookie I set in my handler is
discarded (no matter if I use $r-header_out() or
$r-err_header_out()).
How can I force Apache to send the Set-Cookie header even if the
document being delivered has not changed? I suspect that I am not the
first person
How can I force Apache to send the Set-Cookie header even if the
document being delivered has not changed? I suspect that I am not
the
first person to run into this problem. A search of the list was
unsuccessful, unfortunately.
i've not tested, but it looks like Set-Cookie is left out
set in my handler is
discarded (no matter if I use $r-header_out() or
$r-err_header_out()).
How can I force Apache to send the Set-Cookie header even if the
document being delivered has not changed? I suspect that I am not the
first person to run into this problem. A search of the list
44 matches
Mail list logo
