Agreed - I was saying that any proposal for web mechanisms these days
must not make caching impossible, so we're not conflicting here. The
problem with the cookie proposal was that it made proxy-defeating the
*norm*.
> It's necessary when
> I provide a page that is tailored in some way for a particular user.
Yes - if someone is connecting to a financial company and wants to see how
their portfolio is doing, sure, that can't be cached (it'll most likely be
encrypted anyways). But the question is if you should base that a
Session-ID or a real user-password system. I would vote for the latter.
The real solution is one where the financial company sends the investor a
portfolio-app (Java or otherwise) which queries dowjones.com via HTTP (or
better yet, dowjones.com broadcasts stats via multicasting, which the
portfolio app listens to giving you info real time on your portfolio).
But the debate here is whether using Session-ID is appropriate for
tailoring information.... and I still say no, because I think for every
application where someone can show it's useful, there's a much better
long term solution.
> >In fact, I'd support language in the spec that said "it is strongly
> >recommended that servers not generate content that depends on a
> >particular session-ID value" - what would be ideal is if proxy caches
>
> We differ fundamentally there. I see the Web as a distributed application
> mechanism with the ability to personalize pages to any individual's taste.
> Generating session-id specific content is one of my primary goals.
Yes. Distributed. Absolutely. Custom-creating content for every access
is the opposite. Distribution works *best* when the objects being flung
around the net are as generic as possible (thus highly cacheable), and the
customization happens as close to the client as possible. Make the
clients just as smart, if not smarter than, the servers.
I will admit this doesn't solve content-provider's problems and needs
right now. Those of us who want to provide custom content really do
have to rely on password-based mechanisms or URL hacks for now - but I
don't think the tool-builders need to waste their time with short term
solutions which will just make the content-providers suffer longer (if a
little less).
> >did forward GET If-modified-since requests, *with* the session-ID's, so
> >servers who want it can still get good data without having to dish out
> >the whole file for every request. HTTP-NG sounds like it'll have a way
>
> This gets into where I feel session-ids overlap with security. I'd like not
> to serve certain pages to a person with a different session-id. And perhaps
> not even let them be cached.
So *don't* use Session-ID's for sensitive information! There are lots of
other security work going on, the last thing we need is a parallel
mechanism.
Besides, Session-Id *can't* provide authentication information by itself,
since it's the server issuing them. The server could issue them when a
page is accessed via usual HTTP user authentication of course, but the
thought was to eliminate that.
> >Agreed... which is why I don't think they should carry a session-ID for
> >every store they visit either. :)
>
> That gets to the one major advantage of client-generated session-ids. Of
> course then one needs to determine how to generate a unique user id. There
> are two options that immediately come to mind. Email addresses work pretty
> well (that's what we use to search for an ID if someone loses theirs - we
> just mail the result of the search to them - First Virtual-style security
> :-). The most useful option though would really be a public-key. If every
> user had (a unique) one (or every browser, if must be) then we would have
> an *extremely* useful session-id. If nothing else, it would give the Feds
> nightmares!
Again, *authentication* is entirely separate and should be out of the
scope of Session-ID. Eventually, yes, public-key crypto will allow
people to authenticate themselves without requiring huge user databases
on the server end, but that's not quite the same issue here. Server X
should be able to discern my path through their service without getting
any personal info about me.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/