On 01/27/09 16:04, Jan Luehe wrote:
> On 01/27/09 15:55, Jan Luehe wrote:
>> 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.
>
> I meant "Case 3" should be the default.
>
Actually, I am having second thoughts about what the default behaviour
should be.
The default has always been to enable cookies
(enableCookies=true). There was no separate property for
"enableURLRewriting" (actually, there was one, but it was always
ignored).
Prior to the fix for
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3972
("HttpServletResponse.encodeURL() unconditionally appends jsessionid
if session is newly created")
the jsessionid of a newly created session would be stored both as a
cookie and encoded in the URL, regardless of the value of
"enableCookies".
After the fix for IT 3972, it would be stored as a cookie (and not encoded
in the URL) only if enableCookies=true, and encoded in the URL (but not
stored as a cookie) if enableCookies=false.
Now that I've added support for "enableURLRewriting", I would like for
the default behaviour to be enableCookies=true and
enableURLRewriting=true. This way, both types of browsers (those that
support cookies and those that don't) will be supported out-of-the-box.
This setting would restore the original default behaviour (prior to
the fix for IT 3972), but would break the behaviour introduced by the fix
for IT 3972. However, those who want to enable cookies and disable URL
rewriting will now be able to do so by setting enableURLRewriting to
false.
Therefore, Case 1 will be the default in GlassFish v3.
I've also updated the GlassFish impl of the new
javax.servlet.SessionTrackingMode
feature introduced by the Servlet 3.0 spec to no longer treat the
presence of both
SessionTrackingMode.COOKIE and SessionTrackingMode.URL as an error.
Let me know what you think.
Thanks,
Jan