DO NOT REPLY [Bug 51132] it would ignore the semicolon which contained in the request url
https://issues.apache.org/bugzilla/show_bug.cgi?id=51132 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2011-04-30 19:00:30 UTC --- This took a little digging and some discussion with some httpd folks who are more familiar with the specs that I am but the conclusion is that Tomcat's behaviour is correct. rfc3986 defines dot segments as exactly ".." or ".". This means "..;" is not a dot segment. Further rfc3986 states that interpretation of path parameters is an application concern. Therefore, nginx is correctly normalising when ".." is present and correctly forwarding "..;" to the application. rfc2616 does not add anything in this case beyond what is in rfc3986. The Servlet specification states that path parameters are ignored when mapping requests. Therefore "..;" gets treated ".." for mapping purposes meaning "/g/..;/examples" gets treated as "/g/../examples" for mapping which is normalised to "/examples". Resin's error response is not specification compliant. Tomcat is correctly serving the examples context in this case. This issue is a good example of why relying solely on the mappings of a reverse proxy to deny access to a particular context is likely to be insecure. Due to the impossibility to guarantee that all URLs are handled by Tomcat as they are in proxy servers, Tomcat should always be secured as if no proxy restricting context access was used. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: MIME type additions
On 29/04/2011 19:20, Rainer Jung wrote: > Below I will list the changes. I don't know whether it is a good idea to > grow web.xml that much, but if people think it is useful, I can make our > trunk web.xml mime types consistent with the one from httpd. +1. > We should > expliciteley discuss the inconsistencies given at the start of the below > list though. I am +1 for all your suggested changes. > 5) Long list of additional entries in httpd > > Should we add them (about 600 entries) as is? Yes. > E.g. all of BZ 51137 are > included here. Do we care about the order of the entries (alphabetic or > some performance relevant ordering)? Alphabetical ordering please as it should be at the moment. Much easier to manage. They get out in a HashMap so order here won't impact performance. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51138] New: Cookies with colons in the cookie value are read incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=51138 Bug #: 51138 Summary: Cookies with colons in the cookie value are read incorrectly Product: Tomcat 7 Version: 7.0.12 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: jel...@jteam.nl Classification: Unclassified In my browser I have a cookie with the following name and value name : _mkto_trk value : id:096-SLE-656&token:_mch-localhost-1304194663326-22461 When i try the read this cookie via (HttpServletRequest.getCookies() i will find the cookie but it's value will be id instead of id:096-SLE-656&token:_mch-localhost-1304194663326-22461 this is incorrect This issue seems to have been previously raised on the tomcat-user mailing list http://old.nabble.com/Issue-reading-a-cookie-having-a-colon-in-the-value-.-Is-this-a-bug-in-Tomcat-6.0.32---td30876300.html Where tomcat committer Christopher Schultz blamed the issue on broken user agents citing portions of the rfc2965 spec. While that is in fact true, no major browser besides opera ever implemented RFC 2965 (see also the discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=610218#c11) The following draft most accurately descibes the current status quo http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51139] New: Possible bug in code related to "validatorClassName" property?
https://issues.apache.org/bugzilla/show_bug.cgi?id=51139 Bug #: 51139 Summary: Possible bug in code related to "validatorClassName" property? Product: Tomcat Modules Version: unspecified Platform: PC Status: NEW Severity: normal Priority: P2 Component: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: tkosa...@gmail.com Classification: Unclassified Created attachment 26945 --> https://issues.apache.org/bugzilla/attachment.cgi?id=26945 Add missing validatorClassName prpoerty to ALL_PROPERTIES array I've been trying to configure a connection pool that includes a custom validator class, however it seems like if the "validatorClassName" property is specified in the configuration XML, the property is not getting passed to the new created datasoure implementation in DataSourceFactory. It seems the properties array, ALL_PROPERTIES, in DataSourceFactory does not contain validatorClassName so that property is never propogated? When I add the property to the ALL_PROPERTIES array, it seems to work as I would expect. Have I missed something in the expected configuration? I'll attach a patch for the proposed mod to DataSourceFactory.java. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
