You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Andrew Gilmartin <an...@dynamicdiagrams.com> on 2001/06/19 04:34:53 UTC
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
andrewgilmartin@dynamicdiagrams.com
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
Posted by Andrew Gilmartin <an...@dynamicdiagrams.com>.
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
Posted by Nenad Steric <ne...@teleweb.at>.
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 <do...@covalent.net> 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
> <me...@stonehenge.com> <URL: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
Posted by will trillich <wi...@serensoft.com>.
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
will@serensoft.com
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
Posted by Rob Bloodgood <ro...@empire2.com>.
> 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
Posted by will trillich <wi...@serensoft.com>.
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"
will@serensoft.com
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
Posted by Rob Bloodgood <ro...@empire2.com>.
> > 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
Posted by Nenad Steric <ne...@teleweb.at>.
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
Posted by will trillich <wi...@serensoft.com>.
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"
will@serensoft.com
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
Posted by Andrew Ho <an...@tellme.com>.
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/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: Requests using If-Modified-Since cause response Set-Cookie to
be discarded
Posted by Doug MacEachern <do...@covalent.net>.
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
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Doug" == Doug MacEachern <do...@covalent.net> 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
<me...@stonehenge.com> <URL: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
Posted by Doug MacEachern <do...@covalent.net>.
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
Posted by Nenad Steric <ne...@teleweb.at>.
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.c Tue 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
> andrewgilmartin@dynamicdiagrams.com
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
Posted by Andrew Gilmartin <an...@dynamicdiagrams.com>.
> > 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.c Tue 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
andrewgilmartin@dynamicdiagrams.com
Re: Requests using If-Modified-Since cause response Set-Cookie to
be discarded
Posted by Doug MacEachern <do...@covalent.net>.
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.c Tue Jun 19 09:46:29 2001
@@ -2637,6 +2637,7 @@
"Warning",
"WWW-Authenticate",
"Proxy-Authenticate",
+ "Set-Cookie",
NULL);
terminate_header(r->connection->client);