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.
Jan