Re: $r->headers_out Location and Set-Cookie
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 :) Oh! I totally missed that you're using Apache::Registry. I'm not sure the best way to do it with that, sorry. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org "All I want out of the Universe is 10 minutes with the source code and a quick recompile." - unknown -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r->headers_out Location and Set-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);
$r->headers_out->set(Location => $location);
$r->status(REDIRECT);
$r->send_http_header;
return OK;
How would you have written it?
http://marc.theaimsgroup.com/?l=apache-modperl&m=106260380606735&w=2
thanks, I meant to put that in myself :)
Seems to me you'd want to *return* REDIRECT, not set $r->status to REDIRECT.
Here's what I do in this case:
$r->header_out(Location => $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
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 :)
however, yes, I prefer your way and return REDIRECT instead of OK - it just
seems to make things that much closer to handler behavior, as well as being
a bit more intuitive.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r->headers_out Location and Set-Cookie
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);
> $r->headers_out->set(Location => $location);
> $r->status(REDIRECT);
> $r->send_http_header;
> return OK;
>
>How would you have written it?
Seems to me you'd want to *return* REDIRECT, not set $r->status to REDIRECT.
Here's what I do in this case:
$r->header_out(Location => $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
I've also used $r->internal_redirect($location) for some things, but I don't
think that's appropriate here.
--
Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org
"To dwell on the destination is to waste the journey"
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: FW: $r->headers_out Location and Set-Cookie
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 didn't scan far enough through the list archives. Problem must be at the company mail server. I've been getting infrequent diagnostic messages from various mailing list daemons. Apologies... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: FW: $r->headers_out Location and 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
FW: $r->headers_out Location and Set-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' => $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.
>
> not to mention it's entirely unnecessary (and undesirable) to
> send headers on error responses such as redirects.
Why?
Appendix A.7 from the Stas' Practical mod_perl book states:
> You should use err_headers_out( ), not headers_out( ),
> when you want to send cookies in a REDIRECT response or
> in any other non-2XX response
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);
$r->headers_out->set(Location => $location);
$r->status(REDIRECT);
$r->send_http_header;
return OK;
How would you have written it?
> and you should never set $r->status from a handler - for
> Registry scripts it's ok, since we use it as a hack to get
> around some things, but handlers should never manipulate the
> value of $r->status.
Why is that?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
Re: $r->headers_out Location and Set-Cookie
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 need to call $r->send_http_header, it
> > doesn't exist in mp2.
>
> not to mention it's entirely unnecessary (and undesirable) to
> send headers on error responses such as redirects.
Why?
Appendix A.7 from the Stas' Practical mod_perl book states:
> You should use err_headers_out( ), not headers_out( ),
> when you want to send cookies in a REDIRECT response or
> in any other non-2XX response
that's correct, but setting the headers is entirely different than sending them.
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);
$r->headers_out->set(Location => $location);
$r->status(REDIRECT);
$r->send_http_header;
return OK;
How would you have written it?
the example is wrong - it should not have send_http_header() in it.
if you execute that script over telnet, you'll see two sets of headers.
apache automatically sends headers on errors - that's how you are able to
get standard 500 pages, etc.
> and you should never set $r->status from a handler - for
> Registry scripts it's ok, since we use it as a hack to get
> around some things, but handlers should never manipulate the
> value of $r->status.
Why is that?
if r->status is not HTTP_OK (200) then apache thinks that an ErrorDocument
has _also_ thrown an error, and it thus ends what would otherwise be a
recursive cycle of errors. by messing with r->status, you mess up Apache's
internal bookkeeping wrt the error document cycle.
--Geoff
/me sliently points to recipe 3.13 in the cookbook, too :)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: $r->headers_out Location and Set-Cookie
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);
> >
> > notice that you don't need to call $r->send_http_header, it
> > doesn't exist in mp2.
>
> not to mention it's entirely unnecessary (and undesirable) to
> send headers on error responses such as redirects.
Why?
Appendix A.7 from the Stas' Practical mod_perl book states:
> You should use err_headers_out( ), not headers_out( ),
> when you want to send cookies in a REDIRECT response or
> in any other non-2XX response
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);
$r->headers_out->set(Location => $location);
$r->status(REDIRECT);
$r->send_http_header;
return OK;
How would you have written it?
> and you should never set $r->status from a handler - for
> Registry scripts it's ok, since we use it as a hack to get
> around some things, but handlers should never manipulate the
> value of $r->status.
Why is that?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
Re: Set-Cookie
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 --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
$r->headers_out Location and Set-Cookie
I have the next problem, i am in page A that points to page B, that is
a modperl2 handler.
This handler makes a job and decides to send a cookie to the browser, and
after to redirect to the same page A who is ready to catch the cookie.
Then the problem is that if i put the two headers, 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->{'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
to localhost/pageA (or simply click BACK button) then the browser DO see
the cookie!
Any idea?
-
Un nuevo buscador más rápido, eficaz y sencillo http://www.plaf.com
Ya.com ADSL Home 24h, Módem + Alta + 1 mes Gratis http://acceso.ya.com/adslhome24h/
Re: Re: $r->headers_out Location and Set-Cookie
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 understand that the first is related with an error message
sended by headers, but i mean, really what does apache make different?
I find there is poor docs about that ... maybe i don't know where are the
good docs???
- Original Message -
Ahh, didn't know that.. Thanks Stas!
-Chris
- Original Message -
From: "Stas Bekman"
To: "Chris Faust"
Cc: ;
Sent: Sunday, August 10, 2003 2:37 PM
Subject: Re: $r->headers_out Location and Set-Cookie
> 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 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.
-
Un nuevo buscador más rápido, eficaz y sencillo http://www.plaf.com
Ya.com ADSL Home 24h, Módem + Alta + 1 mes Gratis http://acceso.ya.com/adslhome24h/
Re: $r->headers_out Location and Set-Cookie
On Saturday, Aug 9, 2003, at 15:26 Europe/London, Nick Tonkin wrote:
On Sat, 9 Aug 2003, gerard uolaquetalestem wrote:
I have the next problem, i am in page A that points to page B,
that is
a modperl2 handler.
This handler makes a job and decides to send a cookie to the browser,
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-Cookie + Location
is not compatible (generally - some browsers will accept the cookie).
Matt.
Re: $r->headers_out Location and Set-Cookie
Ahh, didn't know that.. Thanks Stas!
-Chris
- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Chris Faust" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, August 10, 2003 2:37 PM
Subject: Re: $r->headers_out Location and Set-Cookie
> 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 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.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
Re: $r->headers_out Location and Set-Cookie
Stas Bekman wrote:
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 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.
I've added this to the new mp2 cooking chapter:
http://perl.apache.org/docs/2.0/user/coding/cooking.html#Sending_Cookies_in_REDIRECT_Response
it would be useful to port interesting entries from
http://perl.apache.org/docs/1.0/guide/snippets.html
and may be add new ones...
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r->headers_out Location and Set-Cookie
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 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.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Set-Cookie
Hi All, Any idea if "Set-Cookie2:" is going to be implemented in CGI.pm? Lincohn? Regards, Jie
Re: $r->headers_out Location and Set-Cookie
On Sat, 9 Aug 2003, gerard uolaquetalestem wrote:
>
> I have the next problem, i am in page A that points to page B, that is
> a modperl2 handler.
> This handler makes a job and decides to send a cookie to the browser, and
> after to redirect to the same page A who is ready to catch the cookie.
>
> Then the problem is that if i put the two headers, 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->{'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
> to localhost/pageA (or simply click BACK button) then the browser DO see
> the cookie!
>
> Any idea?
Yep. You need $r->err_headers_out->{'Location'} and you could change to
$r->err_headers_out->{'Set-Cookie'} too.
- nick
--
Nick Tonkin {|8^)>
Re: $r->headers_out Location and Set-Cookie
"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 explanation of the difference- http://ken.coar.org/burrow/index?month=2003-07#511 -- Joe Schaefer
Re: $r->headers_out Location and Set-Cookie
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.
not to mention it's entirely unnecessary (and undesirable) to send headers
on error responses such as redirects.
and you should never set $r->status from a handler - for Registry scripts
it's ok, since we use it as a hack to get around some things, but handlers
should never manipulate the value of $r->status.
--Geoff
Re: $r->headers_out Location and Set-Cookie
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 " <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 09, 2003 10:01 AM
Subject: $r->headers_out Location and Set-Cookie
I have the next problem, i am in page A that points to page B, that
is
a modperl2 handler.
This handler makes a job and decides to send a cookie to the browser, and
after to redirect to the same page A who is ready to catch the cookie.
Then the problem is that if i put the two headers, 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->{'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
to localhost/pageA (or simply click BACK button) then the browser DO see
the cookie!
Any idea?
-
Un nuevo buscador mas rapido, eficaz y sencillo http://www.plaf.com
Ya.com ADSL Home 24h, Modem + Alta + 1 mes Gratis
http://acceso.ya.com/adslhome24h/
Re: Location header blows away Set-Cookie?
I think this is in the Guide somewhere, but the short answer is to
use 'err_header_out()' rather than 'header_out' for any type of
non-success result.
On Fri, 12 Apr 2002, Thomas K. Burkholder wrote:
> Apologies if this is well-known - a generalized search failed to explain
> the behaviour I'm seeing.
>
> Using:
>
> Apache/1.3.23 (Unix) Debian GNU/Linux mod_ssl/2.8.7 OpenSSL/0.9.6c
> mod_perl/1.26
>
> I'm using a perl handler in which I create a session and bind it to a
> cookie if a session doesn't 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->header_out("Location" => $redir);
>return REDIRECT;
>
> I use curl to test with - the result does not contain the Set-Cookie
> header. Is it expected behaviour that redirection should blow away
> Set-Cookie headers, and I just have to find a different way to do this?
>
> I'm pretty sure this isn't a caching issue since I'm using curl to
> initiate the test.
>
> Am I barking up the wrong tree?
>
> Thanks in advance for any help-
>
> //Thomas
> Thomas K. Burkholder
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Location header blows away Set-Cookie?
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/
--
Location header blows away Set-Cookie?
Apologies if this is well-known - a generalized search failed to explain
the behaviour I'm seeing.
Using:
Apache/1.3.23 (Unix) Debian GNU/Linux mod_ssl/2.8.7 OpenSSL/0.9.6c
mod_perl/1.26
I'm using a perl handler in which I create a session and bind it to a
cookie if a session doesn't 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->header_out("Location" => $redir);
return REDIRECT;
I use curl to test with - the result does not contain the Set-Cookie
header. Is it expected behaviour that redirection should blow away
Set-Cookie headers, and I just have to find a different way to do this?
I'm pretty sure this isn't a caching issue since I'm using curl to
initiate the test.
Am I barking up the wrong tree?
Thanks in advance for any help-
//Thomas
Thomas K. Burkholder
[cripplecreek:~/MyProjects/WebFetcher/build] burkhold% curl -i
"http://www.areaj.org/areaj?pg=Search&imagesize=thumbnail&editCaptions=no&;
deleteMarkingControls=no&tableHeight=3&tableWidth=3&orderby=random&showExif=
no&showCaptions=none&save=no&navstyle=slideshowauto&showSizeChange=no&editSelection=
no&showNavButtons=no&captionsarea=&editImages=no&showBasic=no&markForDelete=
no&autoInterval=120"
HTTP/1.1 302 Found
Date: Fri, 12 Apr 2002 18:12:37 GMT
Server: Apache/1.3.23 (Unix) Debian GNU/Linux mod_ssl/2.8.7
OpenSSL/0.9.6c mod_perl/1.26
Location:
areaj?pg=GenPage&foo=bar&pg=Search&imagesize=thumbnail&editCaptions=no&deleteMarkingControls=
no&tableHeight=3&tableWidth=3&orderby=random&showExif=no&showCaptions=none&
save=no&navstyle=slideshowauto&showSizeChange=no&editSelection=no&showNavButtons=
no&captionsarea=&editImages=no&showBasic=no&markForDelete=no&autoInterval=
120
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
302 Found
Found
The document has moved here.
[cripplecreek:~/MyProjects/WebFetcher/build] burkhold%
Re: Apache::AuthCookie not set cookie really
> 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 will be set to "/" unless the path has been configured. This will allow people who have configurations that dont specify the path to still use the new version without updating the config. Feel free to grab the source from CVS and try it out at: http://sourceforge.net/projects/ap-authcookie Mike
Re: Apache::AuthCookie not set cookie really
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 solutions require database access while all, what I > want to store in sessions, can get from the same database with no > great effort > > I've decided to use simplest authentication module kinda > Apache::DBILogin and if someone need real security - SSL. I meant Apache::AuthDBI of course > > Thank you > > Sergey Polyakov aka "BeerBong" > Chief of WebZavod http://www.webzavod.ru > Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 > mailto:[EMAIL PROTECTED] > > > > >
Re: Apache::AuthCookie not set cookie really
> > > > 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 correct? > > That would send you to /agenda/login when authen_ses_key() fails, but > your config below is for /LOGIN/. > > > > > AuthType Apache::AuthCookieAgenda > > AuthName Agenda > > SetHandler perl-script > > PerlHandler Apache::AuthCookieAgenda->login > > > > This implies to me that you meant to have: > > PerlSetVar AgendaLoginScript /LOGIN/ > > Is this just a typo? > > > I used Apache::Session::Counted, and know that this two modules may > > conflict, but when all Apache::Session::Counted staff is commented > > result is the same... > > I dont think they conflict. I've not heard any reports of that anyway. > The cookie names are unique so there should be no problem there. > > > I dont know why cookie is not set. > > I'd suspect something isnt right with your configuration. Have you > tried turning on "warn me before accepting cookies" on your browser? > Sometimes that helps me verify that the cookies are actually making it > to the browser. > > What your trying to do looks to me like exactly the sort of thing > AuthCookie can do. Unless I am misunderstanding your problem I > dont see an AuthCookie limitation here. Please explain in more > detail if I am missing the point and I will see what we can do if > such a limitation does in fact exist :). > > Regards, > Michael Schout (Apache::AuthCookie maintainer) SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda->login 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 path attribute. I think, it's a good idea to make WhatEverPath required option in config. with config PerlSetVar AgendaPath /agenda SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda->login all works fine. 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 solutions require database access while all, what I want to store in sessions, can get from the same database with no great effort I've decided to use simplest authentication module kinda Apache::DBILogin and if someone need real security - SSL. Thank you Sergey Polyakov aka "BeerBong" Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: Apache::AuthCookie not set cookie really
> > 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 correct? That would send you to /agenda/login when authen_ses_key() fails, but your config below is for /LOGIN/. > > AuthType Apache::AuthCookieAgenda > AuthName Agenda > SetHandler perl-script > PerlHandler Apache::AuthCookieAgenda->login > This implies to me that you meant to have: PerlSetVar AgendaLoginScript /LOGIN/ Is this just a typo? > I used Apache::Session::Counted, and know that this two modules may > conflict, but when all Apache::Session::Counted staff is commented > result is the same... I dont think they conflict. I've not heard any reports of that anyway. The cookie names are unique so there should be no problem there. > I dont know why cookie is not set. I'd suspect something isnt right with your configuration. Have you tried turning on "warn me before accepting cookies" on your browser? Sometimes that helps me verify that the cookies are actually making it to the browser. What your trying to do looks to me like exactly the sort of thing AuthCookie can do. Unless I am misunderstanding your problem I dont see an AuthCookie limitation here. Please explain in more detail if I am missing the point and I will see what we can do if such a limitation does in fact exist :). Regards, Michael Schout (Apache::AuthCookie maintainer)
Re: AuthSession Manager [was] Apache::AuthCookie not set cookie really
> Application's main goals > 1. Simple install. > I don't want use cron jobs for cleanup - I think, it can be problem > for some users. Most of the existing session stuff is written to leave cleanup to you. If you don't want to use cron jobs, you can do it in a cleanup handler, possibly exec'ing a separate script to avoid keeping the heavy mod_perl process around. > I need to authorize user and don't want to query on every request is > you admin, which departments you belong to etc.. Unless you're willing to put real information in the cookie (not just an ID), you have to do some kind 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 redirect (see above). There's a lot of stuff in the archives about cookies and redirects. Maybe that will help. You're not the first person to have problems with this. > I don't think that it is good to use the Oracle database for > maintaining state or secrets for tickets. It can be slower than query > indexed table even on every request for password and departments where > user works. It's generally fast enough, since it's a single row retrieved by ID. MySQL is very fast at this kind of thing though. - Perrin
AuthSession Manager [was] Apache::AuthCookie not set cookie really
> Hello all!
>
> Odd thing - all should works fine.
> I use Apache::AuthCookie for my project Agenda.
> I wrote descendant - Apache::AuthCookieAgenda
>
> package Apache::AuthCookieAgenda;
>
> use strict;
> use Apache;
> use Apache::Constants qw(:common);
> use Apache::AuthCookie;
> use Agenda;
>
> use vars qw($VERSION @ISA);
>
> $VERSION = substr(q$Revision: 1.1 $, 10);
> @ISA = qw(Apache::AuthCookie);
>
> sub authen_cred ($$\@) {
> my $self = shift;
> my $r = shift;
> my @creds = @_;
>
> # This would really authenticate the credentials
> # and return the session key.
> # Here I'm just using setting the session
> # key to the credentials and delaying authentication.
> #
> # Similar to HTTP Basic Authentication, only not base 64 encoded
>
> join(":", @creds);
> }
>
> sub authen_ses_key ($$$) {
> my $self = shift;
> my $r = shift;
> my($user, $password) = split(/:/, shift, 2);
>
> my $modeller = Agenda->new();
> $r->warn("Auth - $user - $password");
>
> # Authenticate use here...
> $modeller->authorize($user, $password) eq "OK" ? $user : undef;
>
> }
>
> In conf file
>
>
>
> use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules);
> use Apache::Agenda;
> use Apache::AuthCookieAgenda;
>
> PerlInitHandler Apache::Reload
> PerlSetVar AuthCookieDebug 10
>
>
> SetHandler perl-script
> PerlHandler Apache::Agenda
>
> PerlSetVar AgendaPath /agenda
> PerlSetVar AgendaTemplate default.inc
> PerlSetVar AgendaSessionDir /tmp
> PerlSetVar AgendaLoginScript /agenda/login/
>
> AuthType Apache::AuthCookieAgenda
> AuthName Agenda
> PerlAuthenHandler Apache::AuthCookieAgenda->authenticate
> PerlAuthzHandler Apache::AuthCookieAgenda->authorize
> require valid-user
>
>
>
> AuthType Apache::AuthCookieAgenda
> AuthName Agenda
> SetHandler perl-script
> PerlHandler Apache::AuthCookieAgenda->login
>
>
>
>
> when I'm trying to access /agenda/ files I get login page, but after
> submit a form, I return to login page again.
> In logs
>
>
> [Mon Jan 28 12:38:35 2002] [error] credential_0 asdasd
> [Mon Jan 28 12:38:35 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';
> $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:38:35 2002] [error] auth_name Agenda
> [Mon Jan 28 12:38:35 2002] [error] ses_key_cookie
>
> Cookie field is empty here - I don't know why...
> Cookie is set via error headers, I know that it is correct for
> REDIRECT responses...
> ses_key_cookie is empty, therefore authen_ses_key not even
requested,
> redirecting to login form again.
>
> [Mon Jan 28 12:38:35 2002] [error] uri /agenda/tasks/
> [Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
> [Mon Jan 28 12:38:35 2002] [warn] Header Dump:
> GET /agenda/tasks/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/vnd.ms-powerpoint,
> application/ms
> word, */*
> Accept-Encoding: gzip, deflate
> Accept-Language: ru
> Cache-Control: no-cache
> Cookie: SESSION_ID=1000_56535df97f6ed52c
>
> I used Apache::Session::Counted, and know that this two modules may
> conflict, but when all Apache::Session::Counted staff is commented
> result is the same...
>
> Host: warzavod:81
> Referer: http://warzavod/agenda/tasks/
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
> Q312461)
> X-Real-IP: 195.209.67.7
>
> I dont know why cookie is not set.
>
> Is there anywhere comparison table for
> Apache::AuthCookie - Apache::AuthTicket
> and table for
> Apache::Session modules - I use Apache::Session::
Apache::AuthCookie not set cookie really
Hello all!
Odd thing - all should works fine.
I use Apache::AuthCookie for my project Agenda.
I wrote descendant - Apache::AuthCookieAgenda
package Apache::AuthCookieAgenda;
use strict;
use Apache;
use Apache::Constants qw(:common);
use Apache::AuthCookie;
use Agenda;
use vars qw($VERSION @ISA);
$VERSION = substr(q$Revision: 1.1 $, 10);
@ISA = qw(Apache::AuthCookie);
sub authen_cred ($$\@) {
my $self = shift;
my $r = shift;
my @creds = @_;
# This would really authenticate the credentials
# and return the session key.
# Here I'm just using setting the session
# key to the credentials and delaying authentication.
#
# Similar to HTTP Basic Authentication, only not base 64 encoded
join(":", @creds);
}
sub authen_ses_key ($$$) {
my $self = shift;
my $r = shift;
my($user, $password) = split(/:/, shift, 2);
my $modeller = Agenda->new();
$r->warn("Auth - $user - $password");
# Authenticate use here...
$modeller->authorize($user, $password) eq "OK" ? $user : undef;
}
In conf file
use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules);
use Apache::Agenda;
use Apache::AuthCookieAgenda;
PerlInitHandler Apache::Reload
PerlSetVar AuthCookieDebug 10
SetHandler perl-script
PerlHandler Apache::Agenda
PerlSetVar AgendaPath /agenda
PerlSetVar AgendaTemplate default.inc
PerlSetVar AgendaSessionDir /tmp
PerlSetVar AgendaLoginScript /agenda/login/
AuthType Apache::AuthCookieAgenda
AuthName Agenda
PerlAuthenHandler Apache::AuthCookieAgenda->authenticate
PerlAuthzHandler Apache::AuthCookieAgenda->authorize
require valid-user
AuthType Apache::AuthCookieAgenda
AuthName Agenda
SetHandler perl-script
PerlHandler Apache::AuthCookieAgenda->login
when I'm trying to access /agenda/ files I get login page, but after
submit a form, I return to login page again.
In logs
[Mon Jan 28 12:38:35 2002] [error] credential_0 asdasd
[Mon Jan 28 12:38:35 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';
$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:38:35 2002] [error] auth_name Agenda
[Mon Jan 28 12:38:35 2002] [error] ses_key_cookie
Cookie field is empty here - I don't know why...
Cookie is set via error headers, I know that it is correct for
REDIRECT responses...
ses_key_cookie is empty, therefore authen_ses_key not even requested,
redirecting to login form again.
[Mon Jan 28 12:38:35 2002] [error] uri /agenda/tasks/
[Mon Jan 28 12:38:35 2002] [error] auth_type Apache::AuthCookieAgenda
[Mon Jan 28 12:38:35 2002] [warn] Header Dump:
GET /agenda/tasks/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/ms
word, */*
Accept-Encoding: gzip, deflate
Accept-Language: ru
Cache-Control: no-cache
Cookie: SESSION_ID=1000_56535df97f6ed52c
I used Apache::Session::Counted, and know that this two modules may
conflict, but when all Apache::Session::Counted staff is commented
result is the same...
Host: warzavod:81
Referer: http://warzavod/agenda/tasks/
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
X-Real-IP: 195.209.67.7
I dont know why cookie is not set.
Is there anywhere comparison table for
Apache::AuthCookie - Apache::AuthTicket
and table for
Apache::Session modules - I use Apache::Session::Counted as the single
not-database solution wich I found for maintaining state with cleanup
feature. Or is there anywhere cleanup example for Apache::Session - I
didn't find... Apache::Session::Lock::File->clean cleans up only lock
files...
Apache::ASP - has a good session state algorithm with cleanup...
Sergey Polyakov aka "BeerBong"
Chief of WebZavod http://www.webzavod.ru
Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86
mailto:[EMAIL PROTECTED]
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
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
>
> Oh yeah? HOW???
$dbh->do("update sesssion_rec set visit = ? where id = ?",time,$session{id});
or maybe even just
$session{when} = time;
> > if not-modified-since
> > report same
> > else {
> > send headers w/ cookie
> > generate page
> > }
> > }
> > else
> > redirect to login page
> >
> > doesn't look unmanageable to me (until someone shows me the
> > light, of course)...?
>
> How many sessions/day are you running? How big is your DB? How much
> processor do you have to throw at this? (these are the hurdles for storing
> serverside info).
maybe it doesn't scale well, i don't know; it works well for our
purposes. at least you don't have to worry about being unable to
send a new cookie on 'no-changes-since...'. just use the session
id of the existing cookie to 'touch' the session record, updating
the timestamp.
but maybe it's trickier than that for some cases...?
> OTOH, what *benefit* is derived from storing all of this stuff serverside?
"all" in this case is 'timestamp-of-last-request'.
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: Requests using If-Modified-Since cause response Set-Cookie to be discarded
> 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
> report same
> else {
> send headers w/ cookie
> generate page
> }
> }
> else
> redirect to login page
>
> doesn't look unmanageable to me (until someone shows me the
> light, of course)...?
How many sessions/day are you running? How big is your DB? How much
processor do you have to throw at this? (these are the hurdles for storing
serverside info).
OTOH, what *benefit* is derived from storing all of this stuff serverside?
And how about: for the page in question, make an invisible frameset. Use
the request for the FRAMESET (or the invisible frame) to update cookies,
etc, and when the main frame is requested, 304 has already been determined
but timestamps are properly updated.
yes? no?
L8r,
Rob
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
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 tampering with the contents?
> > a MD5-hash would stop them from changing values, but they could
> > still copy the cookie,
> > so the next idea is timeouts, and when you use timeouts it would
> > be nice if the user
> > don't have to login every couple of minutes, but would get a new
> > valid cookie automaticly...
>
> Aside from the fact that a server-side tracking system is bound to become
> incredibly unmanageable, very quickly, in terms of server-side storage...
>
> One of the methods I've used is to include a timestamp in the user's info
> (incl the MD5 hash? see the Eagle for Encryption of Cookies w/ MD5).
>
> THEN, when deparsing the cookie, DELETE it if the timestamp is too old.
>
> THEN, you either have a valid, non-timed out session, or no session at all
> (which is what you were worrying about in the first place, no?). If your
> system is based on session LENGTH (ie this ticket is good for one hour from
> last access), all you have to do is re-set the timestamp to the current
> time.
but he's saying that he can't send a cookie AND do the
'not-changed-since' thing.
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
if not-modified-since
report same
else {
send headers w/ cookie
generate page
}
}
else
redirect to login page
doesn't look unmanageable to me (until someone shows me the
light, of course)...?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: Requests using If-Modified-Since cause response Set-Cookie to be discarded
> > 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 values, but they could > still copy the cookie, > so the next idea is timeouts, and when you use timeouts it would > be nice if the user > don't have to login every couple of minutes, but would get a new > valid cookie automaticly... Aside from the fact that a server-side tracking system is bound to become incredibly unmanageable, very quickly, in terms of server-side storage... One of the methods I've used is to include a timestamp in the user's info (incl the MD5 hash? see the Eagle for Encryption of Cookies w/ MD5). THEN, when deparsing the cookie, DELETE it if the timestamp is too old. THEN, you either have a valid, non-timed out session, or no session at all (which is what you were worrying about in the first place, no?). If your system is based on session LENGTH (ie this ticket is good for one hour from last access), all you have to do is re-set the timestamp to the current time. HTH! L8r, Rob
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
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 independently of > > the entity's Last-Modified date". > > 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 values, but they could still copy the cookie, so the next idea is timeouts, and when you use timeouts it would be nice if the user don't have to login every couple of minutes, but would get a new valid cookie automaticly... I would love to solve this some other way, but i have yet to find an other way. Any ideas ?
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
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 entity's Last-Modified date". maybe storing 'last-access-time' on the server, instead of in the client-side, via cookie, would solve this snafu? -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
Hello, DM>i'm willing to accept a valid reason why set-cookie shouldn't be DM>included 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 in the past. There's just too many bugs out there in caches and clients in dealing with 304s. I tend to assume that if the client sees a 304, auxillary tags (e.g. Expires, cookies, etc.) will be ignored. This reflects the unfortunate real-world state of affairs with RFC noncompliance. My advice is to just try to sidestep this issue where possible. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
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 be included in a 304 response, but i have yet to hear one. let me restate some facts from the thread, quoting rfc 1945: 304 Not Modified If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server must respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field values given in the 304 response. in andrew's case it sounds like set-cookie falls into here: "or which may have changed independently of the entity's Last-Modified date" 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 entity's Last-Modified date". the client stores cached files in a different place than cookies, so set-cookie is not going to invalidate a cached file.
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
Randal L. Schwartz writes > 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? If the HTTP headers were only about the document then I would agree. However, if we look at this set of headers from 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 Content-Type: text/html Then Date, Server, Accept-Ranges, and Connection are about the server while Last-Modified, Content-Length, and Content-Type are about the document. The Set-Cookie could be about either. (I don't know what ETag is for.) In my case, the cookie is related to the user's interaction with the server far more than with the document. So I do think it is valid to return Set-Cookie headers on a 304. -- Andrew
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
Hi Randal, the reason i want this, is that i am building a authentication-scheme which uses tickets to make sure that only one user can be logged in on one account. When the ticket expires and the old user wants another page i want to silently reissue a new ticket if nobody else tried to login with this account. Another idea i might implement is that i could send a changed cookie on every new page, so that even if somebody copied the cookie-file from one computer to another he could not get in as user#1. Makes sense ? (or would you solve this problem in some other way?) "Randal L. 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 with a 304 response. > > 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? > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
>>>>> "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. 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? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
On Wed, 20 Jun 2001, Nenad Steric wrote: > Hi, > > Thanks for your answer, saved me days of probably fruitless fidling around with >modperl. > Your solution solved my problems (see "Sending Cookies on Page-Reload") > the question remains if this violates some RFC's (or breaks some browsers), > and if there is some other way - like faking 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 ?) i passed it along the same day: http://hypermail.linklord.com/new-httpd/2001/Jun/0507.html 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 todo.
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
Hi, Thanks for your answer, saved me days of probably fruitless fidling around with modperl. Your solution solved my problems (see "Sending Cookies on Page-Reload") the question remains if this violates some RFC's (or breaks some browsers), and if there is some other way - like faking 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 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 on purpose > > (maybe an http rfc compliance thing or just a bug), this patch might > > help.. > > > > --- src/main/http_protocol.c~ Tue Apr 17 11:30:14 2001 > > +++ src/main/http_protocol.cTue Jun 19 09:46:29 2001 > > @@ -2637,6 +2637,7 @@ > > "Warning", > > "WWW-Authenticate", > > "Proxy-Authenticate", > > +"Set-Cookie", > > NULL); > > > > terminate_header(r->connection->client); > > I tested it and it works. Thank you for such a quick and authoritative > answer. > > -- Andrew > > --- > Andrew Gilmartin > Ingenta / Dynamic Diagrams > [EMAIL PROTECTED]
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
> > 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 on purpose > (maybe an http rfc compliance thing or just a bug), this patch might > help.. > > --- src/main/http_protocol.c~ Tue Apr 17 11:30:14 2001 > +++ src/main/http_protocol.cTue Jun 19 09:46:29 2001 > @@ -2637,6 +2637,7 @@ > "Warning", > "WWW-Authenticate", > "Proxy-Authenticate", > +"Set-Cookie", > NULL); > > terminate_header(r->connection->client); I tested it and it works. Thank you for such a quick and authoritative answer. -- Andrew --- Andrew Gilmartin Ingenta / Dynamic Diagrams [EMAIL PROTECTED]
Re: Requests using If-Modified-Since cause response Set-Cookie tobe discarded
On Mon, 18 Jun 2001, Andrew Gilmartin wrote: > I have PerlAuthenHandler handler that sets a cookie on authentication > success. The cookie records, in part, the time of the last access to > the site. Therefore for each access the cookie is updated. When a new > document is accessed or a CGI script is run the cookie is sent to the > browser. However, if the browser is asking for a document it has > cached it will send an If-Modified-Since header. The file delivery > mechanism in Apache will do the right thing with If-Modified-Since > information and only send the document if, in fact, it has 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 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 on purpose (maybe an http rfc compliance thing or just a bug), this patch might help.. --- src/main/http_protocol.c~ Tue Apr 17 11:30:14 2001 +++ src/main/http_protocol.cTue Jun 19 09:46:29 2001 @@ -2637,6 +2637,7 @@ "Warning", "WWW-Authenticate", "Proxy-Authenticate", +"Set-Cookie", NULL); terminate_header(r->connection->client);
Requests using If-Modified-Since cause response Set-Cookie to be discarded
I have PerlAuthenHandler handler that sets a cookie on authentication success. The cookie records, in part, the time of the last access to the site. Therefore for each access the cookie is updated. When a new document is accessed or a CGI script is run the cookie is sent to the browser. However, if the browser is asking for a document it has cached it will send an If-Modified-Since header. The file delivery mechanism in Apache will do the right thing with If-Modified-Since information and only send the document if, in fact, it has 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 to run into this problem. A search of the list was unsuccessful, unfortunately. --- Andrew Gilmartin Ingenta / Dynamic Diagrams [EMAIL PROTECTED]
