You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Eric Schneider <er...@centralparksoftware.com> on 2005/05/11 20:46:06 UTC
IRequestCycle cookie madness
Hi,
I'm having trouble getting my head around some behavior that I'm
seeing. Here's the scenario:
I have two components that appear on every page of my application,
component A & B.
When I start a new Visit to the application, the Home page renders
and users can invoke an action on component A that sets a cookie and
returns the next page. Based on the value of this cookie some
behavior on component B should change when the next page is
rendered. Simple enough.
The problem I'm having, for whatever reason, component B is not able
to retrieve the cookie value on the first render after the cookie is
originally set. All subsequent actions (any action, not just the
one related to Component A), component B is able to retrieve the
cookie successfully.
Here's where I get lost trying to figure out how the RequestCycle
works. Both components (A & B) implement PageRenderListener and
define a pageBeginRender(PageEvent event) method (this is where I
attempt get a handle of the cookie). I've added some debugging
output to these methods and the results are a bit puzzling.
After first action is invoked, the order goes something like this:
- Component A: pageBeginRender() is fired
- Component B: pageBeginRender() is fired
- Cookie is written
- Component A: pageBeginRender() is fired (2nd time)
- Component B: pageBeginRender() is fired (2nd time)
- Attempt to retrieve cookie returns null
- Component A: pageBeginRender() is fired (3rd time)
- Component B: pageBeginRender() is fired (3rd time)
- Additional attempt to retrieve cookie returns null
- Next page renders.
The any additional request, the cycle's path seems much simpler:
- Component A: pageBeginRender() is fired
- Component B: pageBeginRender() is fired
- Cookie successfully returns
Anyone have any advice on what's going on here?
Thanks,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: IRequestCycle cookie madness
Posted by Michael Echerer <me...@tngtech.com>.
Barry Books wrote:
> I'm pretty sure that's the case. Perhaps the best way to think of it is setCookie puts a cookie into the response header and getCookie gets one from the request header.
>
Can confirm this. We use a Tapestry service to produce images. If the
session is new, because the home page creates a session and this page
contains an image using the Tapestry service, the service cannot see the
session as the page and image are requested by the browser
simultanously. Hence the sessionid for the cookie is sent back too late
to be used for the concurrent image service request.
As we try the cache images if session data is unchanged, I had to
implement workarounds for users with cookies vs. url rewriting
(basically checking whether a session is new and cookies are used, "old"
sessions are no problem)
>
> On Wednesday, May 11, 2005, at 02:27PM, Eric Schneider <er...@centralparksoftware.com> wrote:
>
>
>>Barry,
>>
>>
>>>>The problem is setting the cookie just puts the cookie into the
>>>>response header. Until the browser makes another request the
>>>>cookie is not really set.
>>
>>Is this really the case? If you set a cookie in a http request, it's
>>not available in the http response? Because I can confirm that the
>>cookie was set in the browser when the response comes back (addition
>>request doesn't seem to be required).
>>
>>I'll try the RedirectException, see if that does the trick.
>>
>>Thanks for the suggestion.
>>
>>e.
>>
>>
>>On May 11, 2005, at 3:01 PM, Barry Books wrote:
>>
>>
>>>>>From the way you describe your code you are trying to retrieve the
>>>>cookie in the same request cycle you set it. The problem is
>>>>setting the cookie just puts the cookie into the response header.
>>>>Until the browser makes another request the cookie is not really
>>>>set. You could either hide this feature by also storing the
>>>>information in the visit object or throw a page redirect exception
>>>>which would cause the browser to retrieve a new page with the
>>>>cookie set.
>>>>
>>>
>>>Barry
>>>
>>>On Wednesday, May 11, 2005, at 01:46PM, Eric Schneider
>>><er...@centralparksoftware.com> wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I'm having trouble getting my head around some behavior that I'm
>>>>seeing. Here's the scenario:
>>>>
>>>>I have two components that appear on every page of my application,
>>>>component A & B.
>>>>
>>>>When I start a new Visit to the application, the Home page renders
>>>>and users can invoke an action on component A that sets a cookie and
>>>>returns the next page. Based on the value of this cookie some
>>>>behavior on component B should change when the next page is
>>>>rendered. Simple enough.
>>>>
>>>>The problem I'm having, for whatever reason, component B is not able
>>>>to retrieve the cookie value on the first render after the cookie is
>>>>originally set. All subsequent actions (any action, not just the
>>>>one related to Component A), component B is able to retrieve the
>>>>cookie successfully.
>>>>
>>>>Here's where I get lost trying to figure out how the RequestCycle
>>>>works. Both components (A & B) implement PageRenderListener and
>>>>define a pageBeginRender(PageEvent event) method (this is where I
>>>>attempt get a handle of the cookie). I've added some debugging
>>>>output to these methods and the results are a bit puzzling.
>>>>
>>>>After first action is invoked, the order goes something like this:
>>>>
>>>>- Component A: pageBeginRender() is fired
>>>>- Component B: pageBeginRender() is fired
>>>>- Cookie is written
>>>>- Component A: pageBeginRender() is fired (2nd time)
>>>>- Component B: pageBeginRender() is fired (2nd time)
>>>>- Attempt to retrieve cookie returns null
>>>>- Component A: pageBeginRender() is fired (3rd time)
>>>>- Component B: pageBeginRender() is fired (3rd time)
>>>>- Additional attempt to retrieve cookie returns null
>>>>- Next page renders.
>>>>
>>>>The any additional request, the cycle's path seems much simpler:
>>>>
>>>>- Component A: pageBeginRender() is fired
>>>>- Component B: pageBeginRender() is fired
>>>>- Cookie successfully returns
>>>>
>>>>Anyone have any advice on what's going on here?
>>>>
>>>>Thanks,
>>>>Eric
>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-
>>>>help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: IRequestCycle cookie madness
Posted by Barry Books <bf...@mac.com>.
I'm pretty sure that's the case. Perhaps the best way to think of it is setCookie puts a cookie into the response header and getCookie gets one from the request header.
On Wednesday, May 11, 2005, at 02:27PM, Eric Schneider <er...@centralparksoftware.com> wrote:
>Barry,
>
>>> The problem is setting the cookie just puts the cookie into the
>>> response header. Until the browser makes another request the
>>> cookie is not really set.
>
>Is this really the case? If you set a cookie in a http request, it's
>not available in the http response? Because I can confirm that the
>cookie was set in the browser when the response comes back (addition
>request doesn't seem to be required).
>
>I'll try the RedirectException, see if that does the trick.
>
>Thanks for the suggestion.
>
>e.
>
>
>On May 11, 2005, at 3:01 PM, Barry Books wrote:
>
>>> From the way you describe your code you are trying to retrieve the
>>> cookie in the same request cycle you set it. The problem is
>>> setting the cookie just puts the cookie into the response header.
>>> Until the browser makes another request the cookie is not really
>>> set. You could either hide this feature by also storing the
>>> information in the visit object or throw a page redirect exception
>>> which would cause the browser to retrieve a new page with the
>>> cookie set.
>>>
>>
>> Barry
>>
>> On Wednesday, May 11, 2005, at 01:46PM, Eric Schneider
>> <er...@centralparksoftware.com> wrote:
>>
>>
>>> Hi,
>>>
>>> I'm having trouble getting my head around some behavior that I'm
>>> seeing. Here's the scenario:
>>>
>>> I have two components that appear on every page of my application,
>>> component A & B.
>>>
>>> When I start a new Visit to the application, the Home page renders
>>> and users can invoke an action on component A that sets a cookie and
>>> returns the next page. Based on the value of this cookie some
>>> behavior on component B should change when the next page is
>>> rendered. Simple enough.
>>>
>>> The problem I'm having, for whatever reason, component B is not able
>>> to retrieve the cookie value on the first render after the cookie is
>>> originally set. All subsequent actions (any action, not just the
>>> one related to Component A), component B is able to retrieve the
>>> cookie successfully.
>>>
>>> Here's where I get lost trying to figure out how the RequestCycle
>>> works. Both components (A & B) implement PageRenderListener and
>>> define a pageBeginRender(PageEvent event) method (this is where I
>>> attempt get a handle of the cookie). I've added some debugging
>>> output to these methods and the results are a bit puzzling.
>>>
>>> After first action is invoked, the order goes something like this:
>>>
>>> - Component A: pageBeginRender() is fired
>>> - Component B: pageBeginRender() is fired
>>> - Cookie is written
>>> - Component A: pageBeginRender() is fired (2nd time)
>>> - Component B: pageBeginRender() is fired (2nd time)
>>> - Attempt to retrieve cookie returns null
>>> - Component A: pageBeginRender() is fired (3rd time)
>>> - Component B: pageBeginRender() is fired (3rd time)
>>> - Additional attempt to retrieve cookie returns null
>>> - Next page renders.
>>>
>>> The any additional request, the cycle's path seems much simpler:
>>>
>>> - Component A: pageBeginRender() is fired
>>> - Component B: pageBeginRender() is fired
>>> - Cookie successfully returns
>>>
>>> Anyone have any advice on what's going on here?
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-
>>> help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: IRequestCycle cookie madness
Posted by Eric Schneider <er...@centralparksoftware.com>.
Barry,
>> The problem is setting the cookie just puts the cookie into the
>> response header. Until the browser makes another request the
>> cookie is not really set.
Is this really the case? If you set a cookie in a http request, it's
not available in the http response? Because I can confirm that the
cookie was set in the browser when the response comes back (addition
request doesn't seem to be required).
I'll try the RedirectException, see if that does the trick.
Thanks for the suggestion.
e.
On May 11, 2005, at 3:01 PM, Barry Books wrote:
>> From the way you describe your code you are trying to retrieve the
>> cookie in the same request cycle you set it. The problem is
>> setting the cookie just puts the cookie into the response header.
>> Until the browser makes another request the cookie is not really
>> set. You could either hide this feature by also storing the
>> information in the visit object or throw a page redirect exception
>> which would cause the browser to retrieve a new page with the
>> cookie set.
>>
>
> Barry
>
> On Wednesday, May 11, 2005, at 01:46PM, Eric Schneider
> <er...@centralparksoftware.com> wrote:
>
>
>> Hi,
>>
>> I'm having trouble getting my head around some behavior that I'm
>> seeing. Here's the scenario:
>>
>> I have two components that appear on every page of my application,
>> component A & B.
>>
>> When I start a new Visit to the application, the Home page renders
>> and users can invoke an action on component A that sets a cookie and
>> returns the next page. Based on the value of this cookie some
>> behavior on component B should change when the next page is
>> rendered. Simple enough.
>>
>> The problem I'm having, for whatever reason, component B is not able
>> to retrieve the cookie value on the first render after the cookie is
>> originally set. All subsequent actions (any action, not just the
>> one related to Component A), component B is able to retrieve the
>> cookie successfully.
>>
>> Here's where I get lost trying to figure out how the RequestCycle
>> works. Both components (A & B) implement PageRenderListener and
>> define a pageBeginRender(PageEvent event) method (this is where I
>> attempt get a handle of the cookie). I've added some debugging
>> output to these methods and the results are a bit puzzling.
>>
>> After first action is invoked, the order goes something like this:
>>
>> - Component A: pageBeginRender() is fired
>> - Component B: pageBeginRender() is fired
>> - Cookie is written
>> - Component A: pageBeginRender() is fired (2nd time)
>> - Component B: pageBeginRender() is fired (2nd time)
>> - Attempt to retrieve cookie returns null
>> - Component A: pageBeginRender() is fired (3rd time)
>> - Component B: pageBeginRender() is fired (3rd time)
>> - Additional attempt to retrieve cookie returns null
>> - Next page renders.
>>
>> The any additional request, the cycle's path seems much simpler:
>>
>> - Component A: pageBeginRender() is fired
>> - Component B: pageBeginRender() is fired
>> - Cookie successfully returns
>>
>> Anyone have any advice on what's going on here?
>>
>> Thanks,
>> Eric
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-
>> help@jakarta.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
Re: IRequestCycle cookie madness
Posted by Barry Books <bf...@mac.com>.
>From the way you describe your code you are trying to retrieve the cookie in the same request cycle you set it. The problem is setting the cookie just puts the cookie into the response header. Until the browser makes another request the cookie is not really set. You could either hide this feature by also storing the information in the visit object or throw a page redirect exception which would cause the browser to retrieve a new page with the cookie set.
Barry
On Wednesday, May 11, 2005, at 01:46PM, Eric Schneider <er...@centralparksoftware.com> wrote:
>Hi,
>
>I'm having trouble getting my head around some behavior that I'm
>seeing. Here's the scenario:
>
>I have two components that appear on every page of my application,
>component A & B.
>
>When I start a new Visit to the application, the Home page renders
>and users can invoke an action on component A that sets a cookie and
>returns the next page. Based on the value of this cookie some
>behavior on component B should change when the next page is
>rendered. Simple enough.
>
>The problem I'm having, for whatever reason, component B is not able
>to retrieve the cookie value on the first render after the cookie is
>originally set. All subsequent actions (any action, not just the
>one related to Component A), component B is able to retrieve the
>cookie successfully.
>
>Here's where I get lost trying to figure out how the RequestCycle
>works. Both components (A & B) implement PageRenderListener and
>define a pageBeginRender(PageEvent event) method (this is where I
>attempt get a handle of the cookie). I've added some debugging
>output to these methods and the results are a bit puzzling.
>
>After first action is invoked, the order goes something like this:
>
>- Component A: pageBeginRender() is fired
>- Component B: pageBeginRender() is fired
>- Cookie is written
>- Component A: pageBeginRender() is fired (2nd time)
>- Component B: pageBeginRender() is fired (2nd time)
>- Attempt to retrieve cookie returns null
>- Component A: pageBeginRender() is fired (3rd time)
>- Component B: pageBeginRender() is fired (3rd time)
>- Additional attempt to retrieve cookie returns null
>- Next page renders.
>
>The any additional request, the cycle's path seems much simpler:
>
>- Component A: pageBeginRender() is fired
>- Component B: pageBeginRender() is fired
>- Cookie successfully returns
>
>Anyone have any advice on what's going on here?
>
>Thanks,
>Eric
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org