[JBoss JIRA] (JBWEB-214) More than one JSESSIONID cookie headers set in JBoss Web
by richard groote (JIRA)
[ https://issues.jboss.org/browse/JBWEB-214?page=com.atlassian.jira.plugin.... ]
richard groote commented on JBWEB-214:
--------------------------------------
I have a question about the status of this issue. In the rfc6265 the below is stated, so it would be nice if the server should not response with multiple session id.
In our situation we do not invalidate the session our self. In our situation we're calling a secure page and than the response contains two SetCookie headers.
The cause of the problem is the session-config in the web.xml defines that the cookie is secure but the call we make in the browser is http.
The next call is a post to the j_security_check and this one will fail with message "session timeout during the login process".
The browser (FireFox and Chrome) are not responding to (correctly) to the Set-Cookie in the first request so therefore a incorrect session is send with the j_security_check.
It would be nice if the server will response only with one Set-Cookie
--- RFC6265 ---
Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for
how user agents handle this case.)
> More than one JSESSIONID cookie headers set in JBoss Web
> --------------------------------------------------------
>
> Key: JBWEB-214
> URL: https://issues.jboss.org/browse/JBWEB-214
> Project: JBoss Web
> Issue Type: Bug
> Components: Tomcat
> Affects Versions: JBossWeb-2.1.11.GA
> Reporter: Eiichi Nagai
> Assignee: Remy Maucherat
>
> More than one JSESSIONID cookie headers set if execute following JSP.
> <%
> session.invalidate();
> session = request.getSession();
> session.invalidate();
> session = request.getSession();
> %>
> This issue has been reported from Bug 49158[1] in tomcat.
> [1] Bug 49158 - More than one JSESSIONID cookie headers set
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49158
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin...
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin...
> I guess that same fix is required in JBoss Web.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda reassigned WFCORE-3545:
----------------------------------
Assignee: Jean-Francois Denise (was: Erich Duda)
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda reassigned WFCORE-3545:
----------------------------------
Assignee: Erich Duda (was: Jean-Francois Denise)
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Erich Duda
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda closed WFCORE-3545.
------------------------------
Resolution: Done
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda reopened WFCORE-3545:
--------------------------------
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda commented on WFCORE-3545:
------------------------------------
This issue has wrong state. It should have status NEW. I will correct it.
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-3545:
---------------------------------------
Test for down key is [here|https://github.com/wildfly/wildfly-core/blob/master/testsuite/standa...], needs to be uncommented after this issue will be fixed.
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months