[
https://issues.apache.org/jira/browse/WICKET-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647289#action_12647289
]
Bruno Borges commented on WICKET-1886:
--------------------------------------
The flow of HTTP communications is always:
REQUEST ---> RESPONSE
** there's no flow like this:
RESPONSE ---> REQUEST
To be more clear, the Response object where you are adding cookies in,
theoretically came from a different request than the one you are trying to get
that cookie back from. So, of course it shouldn't be there. Now, if you create
a request to add the cookie and read the cookie from the response, then on a
second request that cookie should still be there, *if* it's time-to-live makes
sense for this case.
Regards,
Bruno
> WicketTester Cookie handling
> ----------------------------
>
> Key: WICKET-1886
> URL: https://issues.apache.org/jira/browse/WICKET-1886
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 1.3.4
> Reporter: Jörn Zaefferer
> Assignee: Timo Rantalaiho
> Fix For: 1.3.6
>
> Attachments: CookieTest.java
>
>
> While trying to test my SecureForm implementation
> (https://issues.apache.org/jira/browse/WICKET-1885) with WicketTester I ran
> into this issue: A cookie set in the response never shows up in the "next"
> request, because both have their own lists of cookies that aren't shared.
> Afaik both should share the same List instance to handle cookies. That way
> its possible to set a cookie in the response and read it from the request.
> A simple testcase is attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
