Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of bvansickle3@gmail.com
 designates 209.85.210.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=K2njm84NtLR5jYNfWOm/JeV28Xh7zrn9I326mDE9VNCqV/n1S5s6hH8z26PmWJDK4z
         4WUT6YFUALz2iBSe/nXNYvFIiF0DG6GnlwiZ55B2Fa6NY9duN2Wmyaj2K34740+vzABl
         lzWQqAhD2j/ZWD2wTgwZK/6lYWBHlgizmHZHo=
Message-ID: <4AB3AC46.1080208@gmail.com>
Date: Fri, 18 Sep 2009 11:50:30 -0400
From: Brad Van Sickle <bvansickle3@gmail.com>
Reply-To: bvs7085@gmail.com
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
MIME-Version: 1.0
To: Mod_Perl <modperl@perl.apache.org>
Subject: Re: Updating cookies in header during request processing
References: <e86b7d350909180614h37b33895o328bbc2ef94f6248@mail.gmail.com>
	<863a6kfhls.fsf@blue.stonehenge.com> <4AB3A278.9030901@plusthree.com>
 <86y6oce0vf.fsf@blue.stonehenge.com> <4AB3ABC6.7080205@gmail.com>
In-Reply-To: <4AB3ABC6.7080205@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


All due respect, but hat's a little condescending... I generally cringe 
when I hear anyone advocating that there is one "right" way to do things 
that should be used in every instance 

In addition to Michael's points (which are totally valid) I would add 
that  your solution is great for small/medium sized sites but as soon as 
you scale into sites with very large amounts of traffic it quickly 
raises a lot of operational concerns about where to store that data in 
place that's retrievable in a short enough time frame to not degrade 
performance.   Solving that problem is going to cost time and money and 
will sometimes result in your application caring about session affinity, 
which is another operational concern. 

I'm not saying that these problems aren't solvable, I'm simply saying 
that I don't think it's nearly as cut and dried as you seem to, 
especially when you look at the app from and operational perspective. 

I can see both sides of this argument and I can see situations in in 
which either solution might be advantageous over the other.  A lot 
depends on budget, environmental layout, how often the session is 
updated, how much data you're storing, etc... Perhaps you could outline 
in a little more detail why you think storing everything server side is 
the only "right" way to do things? 
>
>
>
> Randal L. Schwartz wrote:
>>>>>>> "Michael" == Michael Peters <mpeters@plusthree.com> writes:
>>>>>>>             
>>
>> Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
>>   
>>>> Ahh, phase 2 of cookie awareness.  When you get to phase 3, you realize that
>>>> cookies should really just be used to distinguish one browser from another,
>>>> and hold everything server-side instead for far better security and
>>>> flexibility.
>>>>       
>>
>> Michael> I disagree. Using cookies for session data has a lot of advantages:
>>
>> [justifications snipped]
>>
>> Yes.  Welcome to phase 2.  Eventually, you'll enter phase 3.  The smarter
>> webdev people always do.  I sounded exactly like you, once, and then grew out
>> of it.  The more you resist, the longer your delay. :)
>>
>>