You could do this just in the browser using just JavaScript. On page load, write a cookie (in JavaScript) and them try to read it: if you get the same result, cookies are enabled. If you get a null result cookies are not enabled. There is not simple JavaScript or DOM variable which indicates that cookies are enabled/disabled.
Otherwise, you need to do as others have proposed: attempt to write a cookie either via JavaScript in the browser or "automatically" by the browser in response to having the server send a cookie request header. Then, have the browser contact the sever again, at which time the browser automatically sends any and all relevant cookies. The server can then read the cookies and reply with success or failure. Personally, I'd do it all in JavaScript in the browser. -- Peter On Aug 3, 2011, at 5:42 PM, webpybuntu <andrubu...@gmail.com> wrote: > Thank you for your reply. My application requires cookies. All I want > to do is display an appropriate message if the user doesn't have > cookies enabled. > > On Aug 3, 6:16 pm, Branko Vukelić <bg.bra...@gmail.com> wrote: >> On 2011-08-03 14:15 -0700, webpybuntu wrote: >> >>> it writes (or attempts to write) a cookie, reads it back, and then >>> deletes it. it tests whether it read the correct value. However, using >>> code like this, I always get None for val2 despite cookies being >>> enabled. Why isn't this working and how can I make it work? >>> Thanks. >> >> Because that's not how HTTP works. Here's how a normal work flow works: >> >> 1: Browser > Server "Howdy!" >> 2: Browser < Server "Oh! Hi, here's a cookie" (cookie attached) >> >> 3: Browser > Server "I need some stuff. And btw, here's the cookie" >> 4: Browser < Server "Hm, yes, that's my cookie. Ok. here's the stuff" >> >> or, it might go like this: >> >> 1. Browser > Server "Hello!" >> 2. Browser < Server "Hi, man. How about a cookie?" (cookie attacked) >> >> 3. Browser > Server "I need some things." >> 4. Browser < Server "Hm, you don't seem to have the cookie on you..." >> >> As you can see, there's always a request-response cycle in pairs. With >> each request-response, the opportunity to set the cookie is when you are >> making a response, and the browser then decides if it wants to show the >> cookie next time it talks to the server. So the opportunity to check the >> cookie is next response. >> >> Now the problem is the "next response". There isn't such a thing as next >> response (unless you are 100% sure that your web app is only ever used >> by one and the same browser that is). The illusion of the next response >> is created using cookies and sessions. So if the browser didn't set the >> cookie you sent it, you never know when that same browser comes to you >> again. >> >> You don't have to worry about cookies to begin with. You should worry >> about the problem you are trying to solve. Are you trying to track the >> browser, to see if it's the same one you talked to before? Is there a >> need to know if it's the same browser or maybe the operation you are >> performing doesn't have to differentiate between different browsers, >> etc. Those are the problems you should focus on. >> >> -- >> Branko Vukelic >> bra...@herdhound.com >> bg.bra...@gmail.com >> >> Lead Developer >> Herd Hound (tm) - Travel that doesn't bitewww.herdhound.com >> >> Love coffee? You might love Loveffee, too. >> loveffee.appspot.com > > -- > You received this message because you are subscribed to the Google Groups > "web.py" group. > To post to this group, send email to webpy@googlegroups.com. > To unsubscribe from this group, send email to > webpy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/webpy?hl=en. > -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to webpy@googlegroups.com. To unsubscribe from this group, send email to webpy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
