Just because it doesn't display in your browser doesn't mean that it wasn't
set. Your browser is caching the page and never sending it to the server
because it doesn't think it has changed. I have not been able to find a
definitive reference on which pragma's should be sent to tell all the
different browsers out there not to cache a page, so if anyone know of one,
please let me know. If you turn on "Show Me the Cookies before you accept
them" in your browser, I think you'll find that the cookie is indeed being
set.
(*Chris*)
----- Original Message -----
From: Jon Williams <[EMAIL PROTECTED]>
To: Chris Pratt <[EMAIL PROTECTED]>
Sent: Monday, March 08, 1999 1:32 AM
Subject: Re: cookies and client pull
>the reason I asked was because I have tried doing it the way you suggest
>and it didn't work completely. As a test, I created an servlet that
>displays the cookies in your browser and a form for inserting a new
>cookie. When submitting the form the servlet returns to itself and
>again tries to display the cookies. This doesn't work because the page
>wont refresh correctly. If you manually refresh, then it displays
>correctly but I dont want to have to manually refresh... (I tried
>setting res "pragma, no-cache" by the way)
>
>Anyways, I am trying to brainstorm a better way of doing this. Any
>ideas?
>
>Jon
>
>Chris Pratt wrote:
>>
>> You would simply create a Cookie object, set the user/password into that
>> cookie, and set the MaxAge (to make sure the cookie persists after the
>> session has ended). Then add the Cookie to the HttpServletResponse
before
>> sending the html page to the client. You probably don't want to wait
until
>> the end of the user session, since you have no idea when the user is
going
>> to end his session.
>> (*Chris*)
>>
>> ----- Original Message -----
>> From: Jon Williams <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Monday, March 08, 1999 12:47 AM
>> Subject: Re: cookies and client pull
>>
>> >I am curious. If you were to prepare a set of pages that would each add
>> >something to the URL and you wanted to parse a user/password cookie from
>> >the URL at the end of the user session and pass it to the browser as a
>> >real cookie... how would that be accomplished easiest???
>> >
>> >Jon
>> >
>> >"Craig R. McClanahan" wrote:
>> >>
>> >> John Evershed wrote:
>> >>
>> >> > Cookies are the easiest way to maintain session state.
>> >> >
>> >> > BUT, if you depend on cookies, you run the risk of the
>> >> > client browser either not being capable of accepting
>> >> > cookies or the browser user deliberately turning cookies
>> >> > off.
>> >> >
>> >> > When this happens, you probably end up creating new session
>> >> > each time that user accesses a page in your application -
>> >> > this could add up to a lot of useless object clutter in your
>> >> > VM (as the new sessions cannot ever be used).
>> >> >
>> >> > Does anyone have a comment on the advisability of the
>> >> > following solution?... [snipped mechanism to tell the user they need
>> >> > cookies]
>> >>
>> >> The Servlet API does offer a standard approach to using sessions even
>> when the
>> >> browser does not have cookies enabled. It is called URL rewriting.
This
>> >> allows you to presume support for sessions without worrying about
whether
>> or
>> >> not cookies are actually being used "under the covers". The only
>> additional
>> >> responsibility you need to do is call HttpServletResponse.encodeUr()
for
>> each
>> >> URL that your servlet generates that points back to this application.
>> >>
>> >> If you really want to not support the user when cookies are disabled,
>> just use
>> >> getSession(false) in your subsequent pages (i.e. once you are past the
>> "home"
>> >> page of the site). If this returns null (because no session id cookie
>> was
>> >> retunred), you can do your error page thing, and not worry about
creating
>> lots
>> >> of useless sessions.
>> >>
>> >> Craig McClanahan
>> >>
>> >>
>>
___________________________________________________________________________
>> >> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>> body
>> >> of the message "signoff SERVLET-INTEREST".
>> >>
>> >> Archives: http://archives.java.sun.com/archives/servlet-interest.html
>> >> Resources:
http://java.sun.com/products/servlet/external-resources.html
>> >> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>> >
>> >--
>> >===========================================
>> >Jon Thor Williams Phish
>> >Java Software Specialist :-)
>> >TrailerSoft [EMAIL PROTECTED] *
>> >"I want to party like it's 1929!" - Unknown
>> >===========================================
>> >
>>
>___________________________________________________________________________
>> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>> >of the message "signoff SERVLET-INTEREST".
>> >
>> >Archives: http://archives.java.sun.com/archives/servlet-interest.html
>> >Resources: http://java.sun.com/products/servlet/external-resources.html
>> >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>> >
>
>--
>===========================================
>Jon Thor Williams Phish
>Java Software Specialist :-)
>TrailerSoft [EMAIL PROTECTED] *
>"I want to party like it's 1929!" - Unknown
>===========================================
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
