I just wanted to add a bit of my own experience on
this...
I have worked on creating applications working over
HTTP for some years now, both thick and thin (ie web
browser) clients. One of the things that has come up
over and over again with regards to cookies is load
balancing. Using the standard servlet way of storing
cookie (in memory), this will mean that a request from
one client will have to come back to the same instance
as the one that created the session, which is usually
solved by adding another cookie. Storing the session
data in a database would solve some of the issues, but
it really turns load balancing into something a lot
more difficould than it has to bee compared to a
simple round-robin of a cookie-less system. And, if
you want to make quick, highly reliable services, load
balancing is almost as king as cache...
--- Rob Heittman <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> Hi Justin,
>
> Purely practical cookie issues:
>
> 1) Browsers that follow the original Netscape cookie
> definition limit a single cookie to 4096 bytes, with
> a maximum of 20 cookies per site. Due to encoding
> issues and overhead your actual storage limit will
> vary by a few bytes. IE recently increased 20 to a
> maximum of 50.
>
> 2) Browsers often have cookies limited in other ways
> (not accepted at all, not accepted beyond the
> browser session or across hosts even though you say
> so, not accepted unless they match certain known
> names, etc.)
>
> 3) Cookies are per browser. They don't identify
> multiple browser entries into your application.
>
> 4) The browser sends EVERY COOKIE back to the
> matching paths on the server in the header of EVERY
> REQUEST. If you poke a whopping 200K of
> not-path-restricted cookies at a client, now that
> client will send 200K of data upstream every time it
> ... i donno ... fetches an image or a CSS stylesheet
> or something from your server. So the
> Netscape-designed 60K limitation was sensible (and
> Microsoft shows the usual consideration by changing
> the limit to 200K for the world's most common
> browser). If the trend continues, any predictions on
> how soon hosting providers drop their "upload
> bandwidth is free" policies?
>
> If the entire amount of state you want to persist is
> guaranteed to fit in less than 4K (or you can rely
> on some kind of splitting approach to set multiple
> cookies for more storage), and you can be sure your
> clients will accept your cookies and respect the
> limits you set, and you really want per-browser
> sessionality, this is probably all the mechanism you
> need.
>
>
> Theoretical cookie issues (with idiomatic Session
> use, not the XML-cookie-storage you described):
>
> The limits on cookies were one impetus driving
> server platform vendors to establish a server-side
> bag of Sessionality, sending a small cookie to
> create affinity with it, and eventually for the
> application server community to canonize this as the
> default idiom. Maybe this happened because the first
> round of commercial Web application servers had
> various session management features as a big selling
> point, and everyone with time to write documentation
> and examples wanted to make sure everybody used the
> heck out of 'em.
>
> But when you elect to keep state on the server, the
> server needs storage for it (which may not scale in
> the large), and the server must be responsible for
> managing it (which means it has to persist across
> restarts, must be available from all cluster nodes,
> etc).
>
> And when you elect to use a cookie as the key to a
> server-side bag of state, you must accept that the
> scope of that state is per browser instance and
> nothing else.
>
> These are valid choices, but I think they are
> choices that developers should actually make , and
> there are lots of alternatives. Take away the
> Servlet Session, and how many of the extant
> servlet-based applications in the world would be
> mortally wounded and need significant porting? 80%?
> 90%? I'm not a rabid RESTian by any means, but I
> can't make myself believe that a server-side hash
> full of state with a cookie-based key was the right
> choice for all of them.
>
> Restlet *does* take away the Servlet Session, and
> thereby makes a developer think what they're going
> to do without it.
>
>
> This thinking process, I feel, takes two forks:
>
> 1) Calling a resource a resource
>
> Typically the stuff that one might put in the
> Servlet Session (e.g. the contents of a shopping
> cart or the result of a database query) is really a
> server-side resource. I advocate giving some thought
> to where it should live (on disk? in memory? as a
> symbol that's reified only upon access?), instead of
> being seduced by a default which does not fit all
> cases. This is where I think Marc was going -- for
> Restlet to provide some handy options for this. And
> after reading some other people's code today, I fear
> that maybe the seductive default in Restlet is to
> stow everything in a file, and that's not really
> good either. So maybe an expanded library of Client
> connectors and some semantics for defining and
> expiring transient resources is the brave way
> forward that Marc called for. If you're still
> reading, Marc, what would you think of something
> like a new Client(Protocol.TEMP) that let you name
> and operate on resources that are meant to be
> transient?
>
> 2) Whatever does not actually need to be a server
> side resource, try hard to give to the client. It
> won't hurt and it's what users expect.
>
> Users want their Back and Forward buttons to work.
> They want to be able to visit a 4-day old page in
> their browser history and pick up from where they
> left off. They want to slap their laptop shut at LAX
> in the middle of an application session, land 13
> hours later in Sydney, snap it open and continue
> without interruption. They want to open three
> simultaneous Firefox windows to your application and
> do different things in each one. They expect these
> things because that's how Web sites (not necessarily
> Web applications) work, and therefore that's how
> they expect everything on the Web to work.
>
> Adherence to the client-side state rule makes a lot
> of this ... just work. The representation you send
> -- the page itself -- the form or whatever -- is
> supposed to contain "all the information necessary
> to understand the request[s]" that might originate
> from that representation. That doesn't actually
> preclude the keeping of server side application
> information (as Yuri just affirmed). If you are on
> Step 3 of a five-step e-commerce checkout process,
> your Step 3 page could actually contain all the
> carried over data from Step 1 and Step 2 (e.g.
> hidden fields), or it could contain some kind of
> identifier pointing to a server-side resource that
> held previously entered data
> (/app/v1/orderforms/{id}), or your browser could
> send a cookie that contained that identifier (if you
> want multiple browser windows to always point to the
> same resource). In any of these ways, the server has
> sufficient information to understand the request and
> act on it.
>
> /rant
>
> :-)
>
> - R
>
>
> ----- Original Message -----
> From: "Stanczak Group" <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Wednesday, September 5, 2007 7:07:25 PM
> (GMT-0500) America/New_York
> Subject: Re: sessions debate (was Re: some
> benchmarking)
>
> Really I had planned on creating an interface that
> uses something like
> XStream with Cookies.
>
> Stanczak Group wrote:
> > So why do cookies not fill this session gap? Is
> that to much client
> > side dependence?
>
>
------------------------------------------------------------
Kyrre Kristiansen
___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good
http://uk.promotions.yahoo.com/forgood/environment.html
