Hi Joerg,
On 01/27/09 13:37, glassfish_at_javadesktop.org wrote:
> Hi Jan!
>
> Read your answer carefully and agree to your argument that two properties are redundant - only IF glassfish should support EITHER cookies OR URL Rewriting.
>
> But in my opinion glassfish could and should support BOTH behaviors in parallel as well as let the dev opt for either or. My case is a current webapp where some client browsers MAY deny cookies while others will accept them.
>
> Currently I cant serve both clients but rather have to decide A) to choose the common denominator - url rewriting - which works for both client browsers OR B) work with cookies and deny service to not-accepting clients, telling them to enable cookies.
>
> I did not dig into the specs for j2ee server session tracking behavior but otherwise stated i do not see a reason why "BOTH behaviors in parallel" should not be possible. A hint to this, contrary to your opinion, is that currently TWO properties are specified in session manager properties. On the other side i do wonder why since nearly one year nobody has objected, or at least unit-tested, what i am suspecting, to be a bug.
>
Thanks for bringing this up!
I just had an email exchange with Paul Carter-Brown (cc'ed) regarding
this very topic.
This is what Paul wrote:
> Hi,
>
> I changed the setting and it now works without cookies. My assumptions
> were correct however in that if I enable cookies on the browser, the
> server still rewrites URL's. Personally I think that the way it was
> before was much better in that the server effectively assumes the
> worst case (there is no cookie support) and rewrites the first URL and
> sets a cookie. If a request has a cookie, then it would no longer
> rewrite the urls. This is the way all other web containers do it so I
> dont see why Glassfish should be any different. The link you attached
> shows that the initial problem people had could have been erradicated
> by turning off URL rewriting in their setups as opposed to regressing
> the default setup.
... and this is how I replied:
--- BEGIN REPLY ---
The link mentioned that people were concerned about the security
implications of exposing
a jsessionid inside a URL when they were not expecting the URL to be
rewritten (since their
webapp was declared to support cookies, via "enableCookies" set to "true").
In the case referred to by the link, people did not want the jsessionid
to be encoded in the URL.
They were under the impression that by setting "enableCookies" to
"true", their concerns
would be addressed.
There was no way for them to express that they wanted to disable URL
rewriting other than
by setting "enableCookies" to "true" (since "enableURLRewriting" was
being ignored at the time
the issue was filed).
Now that I think about it, maybe "enableURLRewriting" should be a
property in its own right,
and it should be possible to set both "enableCookies" and
"enableURLRewriting" to true at the
same time. The way I just fixed
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
("server log message says enableURLRewriting is not supported") in
GlassFish v3 is to treat
this as an error case, but maybe that's too restrictive.
Perhaps both properties should be supported, with these semantics:
Case 1:
enableCookies: true
enableURLRewriting: true
-> jsessionid of new session stored in cookie *and* encoded in URL
Case 2:
enableCookies: true
enableURLRewriting: false
-> jsessionid of new session only stored in cookie (and not encoded in URL)
Case 3:
enableCookies: false
enableURLRewriting: true
-> jsessionid of new session only encoded in URL (and not stored in cookie)
Case 4:
enableCookies: false
enableURLRewriting: false
-> invalid
I believe Case 1 should be the default.
Would you agree?
--- END REPLY ---
Thanks,
Jan
> Jörg
> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328483
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>