Santiago Gala wrote:
>
>
> I have just got a report from a customer that session tracking with no
> cookies enabled breaks when the maximize/restore button is hit. I will
> research it before thursday if nobody corrects it before.
>
> It looks like the URL is not properly rewritten in the MarkRefPage
> action or "around" :-)
>
> I'm currently out of the office, and won't be back until Thursday morning.
>
When jakarta.apache.org finishes the unscheduled maintenance tasks
undergoing :) I will commit some changes related to this problem.
The problems are various:
- In URILookup calls, sometimes parameters are not passed, which means
that some portlets loose state.
- Also in URILookup, the ";jsessionid=" string is cut without paying
attention to the fact that a query string or anchor could be there.
Again, parameters die in the process.
- Again in URILookup, the relative URIs are re-encoded. Tomcat refuses
to encode session info in relative uris. I'm not sure if this is right
even after reading servlet spec 2.2 & 2.3
I'm very grateful to Fernando, who spent several hours tracking this
problem and discussing alternative solutions with me.
The solution is:
- pass parameters in every call to URILookup if they are in the RunData
- Take out the stripping/encoding session id code in URILookup
The assumption is that if we retrieve a URI from the session, this means
that the session is valid, and that the URI was rightly encoded when
stored there. Also, we are assuming that a session will have constant id
during its life.
I could be wrong, but then, the logic should be:
- If URIs need to be stripped of session info, look for query string "?"
or anchor "#" and don't drop them
- Don't ever pass a relative URI to tomcat's response.encodeURL(). Pass
it absolute and then "cut it" to relative after this. Don't know about
other servlet containers.
About tomcat 3.2.2, I'm not sure if its behaviour is right WRT:
- already encoded strings passed to response.encodeURL(String) are not
checked for ";jsessionid=", just appended a new sessionid. The resulting
encoded URL will be wrong, as later the tomcat engine will look only for
the *first* string.
- I think that relative urls *should* be encoded if under the same
context. The problem here is that HttpServletResponse does not have a
way to recover the request URI, so if they do it they should find the
base URI of the original request using a non standard API.
I will report this to tomcat, again when jakarta is done with
maintenance work.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
