Re: session lost with tomcat 4.1.21 (4.1.18)& utf-8 url's?

Hmm... I just checked the Servlet spec v2.3 and section SRV.13.2 says:

"URI paths specified in the deployment descriptor are assumed to be in URL
decoded form."

Which makes me think that I should NOT decode them in the interest of spec
compliance. Unless someone can convince me why I should (I know it might be
convenient, but spec-compliance takes precedence in this case), I plan to
not decode the url-pattern stuff from securityfilter-config.xml.

-Max

----- Original Message -----
From: "Max Cooper" <[email protected]>
To: "Torgeir Veimo" <[email protected]>; "securityfilter"
<securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Sent: Thursday, March 27, 2003 3:09 AM
Subject: Re: [securityfilter-user] session lost with tomcat 4.1.21 (4.1.18)&
utf-8 url's?


> ----- Original Message -----
> From: "Torgeir Veimo" <[email protected]>
> >
> > Maybe the config file can follow the exact same rules for utf encoded
> > paths as browsers do, so that a path can be specified as
> > /main%2Fpages%2Fgroups . There's no need to use the % sign in any other
> > way anyway?
>
> That makes sense to me. I am sure that there is some way to encode the '%'
> character so that it can still be used in url-patterns if needed. I don't
> see much use for it, either, but I'd hate to eat it and find out that it
is
> useful later.
>
> >
> > I think that securityfilter should decode the path, since when a browser
> > encounteres a url such as /pages/æøåæøåhmm/, it might choose to encode
> > the '/'s as well. Furthermore, a browser might encode with both
> > utf-8/16/32, and isolatin1 chars encodes differently in utf-8 than
> > utf-16.
>
> I will add url-pattern decoding. I already fixed the other part of this
> issue, so I should have a release ready soon with the complete solution. I
> am rather time constrained this week, but I want to get a fix out quickly
> and I can never get to sleep anyway, so it will probably be in the next
few
> days. :-)
>
> >
> > The strange thing was that the session was lost. Did you find any
> > possible reason for that? My testing found that if the '/'s was not
> > utf-8 encoded, the session was intact.
>
> I didn't find anything that is an obvious explanation for that. Hopefully
> the general fix will also fix that problem. It seems like there is a good
> chance since the utf encoding of the URL seems to trigger the problem.
>
> -Max
>
> >
> > --
> > Torgeir Veimo <[email protected]>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > securityfilter-user mailing list
> > securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/securityfilter-user
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> securityfilter-user mailing list
> securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/securityfilter-user
>




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en