[Sigia-l] URL design - mixing apples and oranges and tomatoes FORK: Session Cookies, etc

[Joe 10 Enterprises]

There's a pretty good article (with regard to readable URLs, not 
session variables) on phpbuilder from some time ago:

http://phpbuilder.com/columns/tim19990117.php3

RE session SID storage, the cookie/no cookie thing can be somewhat 
overcome by the write-it/read-it back/ if not there pop it onto the 
URL routine with varying degrees of success and overhead.

Session Variables and their management is a big topic anyway, as a) 
they're not entirely secure when appended to the URL and b) flaky 
when used with cookies.

I think the accepted standard is becoming that if you are going so 
far as to use sessions, then you kind of have the right to say "Hey, 
you have to have cookies enabled to proceed"

/Joe

At 1:28 PM -0400 4/14/02, Ziya Oz wrote:
>"PeterV" wrote:
>>  Simple, static, no. I *was* referring to sites that don't need to keep
>>  session - that doesn't mean they can't be dynamic (but I guess it's all
>>  semantics).
>
>By dynamic I mean a 'page' that doesn't physically exist but is created in
>real-time from variable components by app/web servers, all triggered from a
>web client requesting a URL. So (unless you want to serve the same page over
>and over again :-) even for a moderately large site, you have to have some
>efficient scheme of differentiating one such dynamic page from another. Thus
>your URL will have to have some sort of unique name/ID, even without a
>session ID.
>
>>>  Otherwise, dynamically-generated sites need to store session data and/or
>>>  other variables to be used to re-create a bookmarked page.
>>
>>  Only sites that keep sessions need to do that.
>
>Please see above.
>
>>  And only for users that don't have cookies turned on, so in URL design it's
>>  only a small subset of all cases.
>
>Unless you're in a position to *dictate* cookie usage -- and you rarely are
>-- you have to accommodate unique IDs in your URLs for session and/or unique
>page referral.
>
>Incidentally, cookies are not without problems: they can be turned off, get
>deleted or corrupted; the user may switch the hard disk, reformat it, use a
>different browser or a computer; indeed, the same page may be accessed by a
>different, non-PC client; finally, there's a limit to how much stuff you can
>stash in a cookie.
>
>So unless you're a dealing with a small subset of cases where you can
>mandate cookies, any serious web app will have to consider non-cookie usage
>and prepare to deal with URL IDs of one sort or another. That is, back to
>square one.
>
>>>  domain.com/42346DDR6577823TL
>>
>>  Really don't like it. Not readable or hackable.
>
>Why does it have to be 'readable'? Dynamically generated pages really don't
>have to have *any* file path at all for you to traverse, beyond the domain.
>
>>  Agreed, 99% of user will never hack a URL, or even look at it, but if you're
>>  going to design them I think you may as well do it nicely.
>
>Well, the above URL is bookmarkable, can contain session and/or other data,
>gets you to a precise page and it's by far the shortest you can design.
>
>I'm not sure why I'd have to expose my file/directory structure in the URL
>for you to 'hack', especially if my pages are dynamically generated and
>don't reside in directories or are defined by them. I thought the navigation
>bars were designed for, well, navigation :-)
>
>Best,
>
>Ziya

-- 
Joe Tennis
Information Design Honcho
Joe 10 Enterprises
2430 5th Street
Studio L
Berkeley, CA 94710
510-649-1744
joe at joe10.com
http://www.joe10.com
Usability Consulting | Information Architecture | Interface Design
for Web, Wireless and Interactive Media
-------------------------------------------------------
                      OUTDOORSITES.COM
          it's live! -> http://www.outdoorsites.com
-------------------------------------------------------
It's been 6 months since September 11.
What are you thinking?
Share your reflections & memories:
http://911.joe10.com