....just verified that "Cache-Control: no-cache" is real, not supported
by all (esp older) browsers, probably supported by most current
browsers and all http1.1 network caches. Causes back-button to
reobtain from server.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

Fleeing from the madness of the . jungle
hug <contact_info@sig_line.clickit> stumbled into news:alt.www.webmaster
and said:

Have you read this? http://www.mnot.net/cache_docs/

Mark Nottingham is widely regarded as the primary source of real world
info wrt the mysteries of web cache

--
William Tasso

whither a trophy?

hug <contact_info@sig_line.clickit> wrote:

Got it. The pal-guy is going to have a referrer field that is missing
the state identifier, the real guy's referrer field will contain it.
<duh!>

I'm going to need to make a few (lol, Murphy never sleeps) changes
like strengthening the encapsulation of state-change code, taking
ip-addr out of the state-id, and taking advantage of the fact that
browser caching can be prevented via the "Cache-Control" header, but
it's clearly doable. Thanks for your help, all.

It's unfortunate that when they went to http 1.1 they strengthened
http basic auth by adding the digest mechanism and left it at that.
If they had added a tiny bit of functionality to basic auth the whole
where-to-store-session-id question would be handled by giving the
server a method of assigning a userid/password pair to a browser that
it could then use in response to a basic-access challenge. So it
goes.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

hug wrote:
Any particular reason?

hug wrote:
About AOL:
http://betapundit.blogspot.com/2006/...xperience.html

Tony <tony23@dslextreme.WHATISTHIS.com> wrote:

Users can turn cookies off.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

Pondering the eternal question of "Hobnobs or Rich Tea?", hug finally
proclaimed:

You could use the query string at the end of the URL instead. For
example:

example.com/page.ext?sessionid=xxx

Where xxx identifies the user's session id. That way you just
dynamically add the session variable to the end of each URL on your
site, and you can track the visitor's progress through the site that
way.

It's slightly more reliable than using cookies, but it could be a major
PITA to implement.

--
Dylan Parry
http://electricfreedom.org -- Where the Music Progressively Rocks!

hug wrote:
So, you get the result you want for the users who have cookies turned
on, and you get what you're already getting for the users who turn them off.

Seems like that gets you closer to what you want, at least.

Dylan Parry <usenet@dylanparry.com> wrote:

That's essentially how I'm doing it, Dylan. The problem with that
approach (see two posts up) is that if someone forwards a link pasted
from their browser to a friend the friend gets the sessionid as part
of the link. Unless referrer is checked (or something else I've not
yet thought of) the friend could see data he shouldn't. As for it
being a major pita to implement... yes and no. I have code in place
that does a last-minute "browser adjustment" on all html that is sent
out, it does things like add sessionid, convert mailto links, make
offsite links open in a new window, convert symbols unknown to legacy
browsers, and cetera. It was a major pita, it no longer is.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

And lo, Tony didst speak in alt.www.webmaster:
Exactly. IMHO, users who knowingly browse with cookies disabled come to
*expect* troubles with ecommerce of any kind. With https, first-party
cookies are relatively safe these days.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#sear - Orca Search - PHP/MySQL site
search engine