Comments inline On Wednesday 08 October 2003 10:23 pm, Chris Shiflett wrote: > --- Evan Nemerson <[EMAIL PROTECTED]> wrote: > > Well you can change the default from 30 mins to something larger, > > but that has security consequences... > > I am speaking to myself as much as anyone, but we should all try to develop > the habit of explaining any such "consequences" that we mention. To do > otherwise doesn't really educate the many people who read these responses, > whether now or in an archive. It only adds to the mystery of certain topics > (such as security).
Well, they _can_ always ask if they don't understand. I agree that it's best to give as much information as possible, but that takes a LOT of time. If we don't assume any prior knowledge, answering anything would be a huge pain. That being said, I agree that in this case I should have elaborated... It's probably a reach for a lot of list readers. If you have long sessions, the likelyhood that someone will be able to steal the session ID and imitate the user increases drastically. It's called session hijacking, and any google search (or archive search, probably) will yield a wealth of information. > > > Sessions are kind of a hack over HTTP, which is pretty much a > > stateless protocol. There's Connection: keep-alive, but not every > > browser supports it, and I don't think there's a way to hook into it > > from PHP. > > Well, persistent connections aren't really intended to provide stateful > transactions (and they don't). They most certainly are not, but if they could _theoretically_ be used that way. Practicality, however, forbids it. IMO it's a Bad Idea, but still worth mentioning. Actually, now I'm thinking about writing a POC just to see if it can be done, even in a laboratory setting. > > My favorite example to use is Google, because there are two resources that > make up the front page: the HTML and the logo. With previous versions of > HTTP, unless a persistent connection was specifically requested, a separate > TCP connection was established for each transaction. This meant two TCP > connections would be created and destroyed just to render Google. Imagine > more elaborate sites, and you can see how this can really cause performance > problems. By making persistent connections the default (HTTP/1.1), a single > TCP connection can be established, and until all necessary resources are > received, the same connection is used. This makes much more sense. The > Connection header allows you to specify the desired behavior. Wow they finally have one image! IIRC, for a long time the logo was several small images that looked like a single image. That way, the whitespace around the letters didn't have to be included in the image. IMHO that was a cool solution. They still avoid superfluous line breaks, which makes me happy... > > Oh, and every major browser I am aware of does support it, but hopefully > you can now see that it is not associated with sessions or even stateful > transactions. Okay well then here's another reason not to rely on keep-alive: Users can't copy a URL and paste as an argument to wget -c (or any of the download managers). I'm sure there are many, many more reasons, but I sincerely doubt I'd have to convice anyone not to use keep-alive for sessions. > > Hope that helps. > > Chris > > ===== > My Blog > http://shiflett.org/ > HTTP Developer's Handbook > http://httphandbook.org/ > RAMP Training Courses > http://www.nyphp.org/ramp -- Evan Nemerson [EMAIL PROTECTED] -- "Who controls the past controls the future. Who controls the present controls the past." -George Orwell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
