[Bug 56065] New: negative seek offset
https://issues.apache.org/bugzilla/show_bug.cgi?id=56065 Bug ID: 56065 Summary: negative seek offset Product: Tomcat 7 Version: 7.0.5 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Examples Assignee: dev@tomcat.apache.org Reporter: sathishy...@gmail.com Zip4j unzip with password problem,negative seek offset,Zip Exception.Though the my file is not corrupted still I am getting the problem -- 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
[Bug 56065] negative seek offset
https://issues.apache.org/bugzilla/show_bug.cgi?id=56065 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Konstantin Kolinko --- > 2014-01-26 > Version: 7.0.5 Bugzilla is not a playground. -- 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
svn commit: r1561486 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Sun Jan 26 13:41:01 2014 New Revision: 1561486 URL: http://svn.apache.org/r1561486 Log: Add related Bugzilla issue Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1561486&r1=1561485&r2=1561486&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Jan 26 13:41:01 2014 @@ -30,6 +30,7 @@ PATCHES PROPOSED TO BACKPORT: * Fix error when running in strict servlet compliance mode with Java 5. See "Tagging 6.0.39" thread on dev list. + By the way, it fixes https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 https://people.apache.org/~kkolinko/patches/2014-01-26_tc6_schemas_Java5.patch +1: kkolinko -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1561535 - /tomcat/trunk/.gitignore
Author: jboynes Date: Sun Jan 26 19:23:55 2014 New Revision: 1561535 URL: http://svn.apache.org/r1561535 Log: add .idea project directory to git ignores Modified: tomcat/trunk/.gitignore Modified: tomcat/trunk/.gitignore URL: http://svn.apache.org/viewvc/tomcat/trunk/.gitignore?rev=1561535&r1=1561534&r2=1561535&view=diff == --- tomcat/trunk/.gitignore (original) +++ tomcat/trunk/.gitignore Sun Jan 26 19:23:55 2014 @@ -28,6 +28,7 @@ mvn.properties .fbprefs .project .settings +.idea *.iml *.asc *.jj - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Git
On Jan 21, 2014, at 1:58 AM, Mark Thomas wrote: > I've been using Git more and more for Tomcat development and was > wondering what folks thought about moving Tomcat to git. This isn't a > formal proposal or a vote, I'm just trying to gather some views. > > On the plus side: > - it is much easier to have multiple issues in progress at the > same time and switch between them > - being able to work off-line but still commit is a huge benefit > when working on a complex issue and you don't have internet > access > - merging between branches (assuming all supported branches were in a > single repo) is simpler > > Neutral > - we would need to agree some simple guidelines for how we used git > - tooling seems equivalent to that available for svn (at for what I > use anyway) > > On the down side: > - there is much more potential to mess things up > - cleaning up is potentially more complex > - the disruption of the move - particularly if we want to move to a > single git repo - could be significant > > > Thoughts? Generally +0 I think the ability to work offline on multiple issues can be a double edged sword. I just did that this week and having Git would have been helpful. The downside is that it makes it easier to work more in isolation rather than collaborating with other developers. In a quick experiment, I tried Git with some cookie changes and now have a series of changes to merge in one go rather than incrementally and I think that will be harder to review. Having said that, this may just be an artifact of using git with svn as I think if the primary repo was natively Git then I would have done that work in a feature branch in the shared repo. I’ve not followed this on infra@ but from what I understand the web tooling at Apache lags behind SVN's. There’s a richer interface at GitHub but that’s moving yet more away from the Apache community. I’ve found the web view very useful when working with people who are not engaged in the project on a regular basis. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
[Tomcat Wiki] Update of "Cookies" by jboynes
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "Cookies" page has been changed by jboynes: https://wiki.apache.org/tomcat/Cookies?action=diff&rev1=30&rev2=31 Comment: Update implementation progress and link to a new set of patches ##language:en = Cookies = + + == Implementation Progress == + I started work on this in a local branch. Patches for the changes made there can be found here: + http://people.apache.org/~jboynes/patches/ + There is substantial refactoring in there to simply the current implementation. Actual changes are: + * C3 '=' is now disallowed in Netscape cookie names (it was already not allowed in RFC2109 names) + * C4 Attribute names are allowed as cookies names + * Cookie names starting with '$' are allowed in Netscape and RFC6265 mode and will still throw an IAE in RFC2109 mode == Round Trip Behaviour == The following tables document how a value is sent in a Set-Cookie header, what gets stored by a typical browser, the Cookie header that is generated by the browser and then the final value returned to a Servlet application. @@ -56, +64 @@ C5 Allow unnamed cookies in C1b "netscape" mode:: :: Allow cookies whose name is null or the empty string. Browsers will store a single cookie that has no name whose value is sent as simply «value» (i.e. without any '=' delimiter). This would now be supported if STRICT_NAMING is set to "netscape" but would remain disallowed in "rfc2109" or "rfc6265" modes. If allowed, the Set-Cookie header would contain just the value (no '=' present and an IAE if value contained an '=') and any such cookie found during parsing would be included in the result of HttpServletRequest#getCookies(). - A candidate patch for these Cxx changes can be found here: - http://people.apache.org/~jboynes/patches/cookie.patch - This follows proposal C1 with the consequence that a "/" is not allowed in a cookie name by default; to allow that STRICT_NAMING must be set to false (i.e. to "netscape" mode). The test suite changes are a result of that and with them in place I have verified it still passes. - === Changes to generation of Set-Cookie header === G1 Use RFC6265 format header for V0 cookies:: :: When version == 0 always generate a RFC6265 header, raising an exception from addCookie if the value is invalid rather than attempting to upgrade to a RFC2109 header to use quoting. Application impact is that they will now fail fast with an error rather than inconsistent data as described in Bug 55920; applications that do not set invalid values will not be impacted. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1561548 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Sun Jan 26 21:30:29 2014 New Revision: 1561548 URL: http://svn.apache.org/r1561548 Log: Vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1561548&r1=1561547&r2=1561548&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Jan 26 21:30:29 2014 @@ -32,7 +32,7 @@ PATCHES PROPOSED TO BACKPORT: See "Tagging 6.0.39" thread on dev list. By the way, it fixes https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 https://people.apache.org/~kkolinko/patches/2014-01-26_tc6_schemas_Java5.patch - +1: kkolinko + +1: kkolinko, markt -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1561552 - in /tomcat/tc7.0.x/trunk: ./ res/ res/META-INF/ res/confinstall/ res/deployer/ res/ide-support/eclipse/ res/maven/ res/scripts/
Author: kkolinko
Date: Sun Jan 26 21:56:50 2014
New Revision: 1561552
URL: http://svn.apache.org/r1561552
Log:
Merged revisions r1561067-r1561070 from tomcat/trunk:
Remove $Id keyword from res/**
Remove svn:keywords property from res/**
svn propdel svn:keywords --depth infinity
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/res/INSTALLLICENSE (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/annotations-api.jar.manifest (props
changed)
tomcat/tc7.0.x/trunk/res/META-INF/bootstrap.jar.manifest (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/default.manifest (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/el-api.jar.manifest (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.license (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.manifest (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.license (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.manifest (props changed)
tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.notice (props changed)
tomcat/tc7.0.x/trunk/res/confinstall/tomcat-users_1.xml (props changed)
tomcat/tc7.0.x/trunk/res/confinstall/tomcat-users_2.xml (props changed)
tomcat/tc7.0.x/trunk/res/deployer/build.xml (props changed)
tomcat/tc7.0.x/trunk/res/ide-support/eclipse/eclipse.classpath (props
changed)
tomcat/tc7.0.x/trunk/res/ide-support/eclipse/eclipse.project (props
changed)
tomcat/tc7.0.x/trunk/res/maven/README.txt (contents, props changed)
tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-api.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-catalina-ant.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-catalina-jmx-remote.pom (props
changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-catalina-ws.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-embed-core.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-embed-jasper.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-embed-logging-juli.pom (props
changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-embed-logging-log4j.pom (props
changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-es.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-fr.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-ja.pom (props changed)
tomcat/tc7.0.x/trunk/res/maven/tomcat-util.pom (props changed)
tomcat/tc7.0.x/trunk/res/scripts/check-mime.pl (contents, props changed)
tomcat/tc7.0.x/trunk/res/tomcat.nsi (contents, props changed)
tomcat/tc7.0.x/trunk/res/welcome.bin.html (props changed)
tomcat/tc7.0.x/trunk/res/welcome.main.html (props changed)
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1561067-1561070
Propchange: tomcat/tc7.0.x/trunk/res/INSTALLLICENSE
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/annotations-api.jar.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/bootstrap.jar.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/default.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/el-api.jar.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.license
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.license
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.manifest
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/META-INF/servlet-api.jar.notice
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/confinstall/tomcat-users_1.xml
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/confinstall/tomcat-users_2.xml
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/deployer/build.xml
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/ide-support/eclipse/eclipse.classpath
('svn:keywords' removed)
Propchange: tomcat/tc7.0.x/trunk/res/ide-support/eclipse/eclipse.project
('svn:keywords' removed)
Modified: tomcat/tc7.0.x/trunk/res/maven/README.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/res/maven/README.txt?rev=1561552&r1=1561551&r2=1561552&view=diff
==
-
svn commit: r1561565 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Sun Jan 26 22:40:14 2014 New Revision: 1561565 URL: http://svn.apache.org/r1561565 Log: Vote. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1561565&r1=1561564&r2=1561565&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Jan 26 22:40:14 2014 @@ -32,7 +32,7 @@ PATCHES PROPOSED TO BACKPORT: See "Tagging 6.0.39" thread on dev list. By the way, it fixes https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 https://people.apache.org/~kkolinko/patches/2014-01-26_tc6_schemas_Java5.patch - +1: kkolinko, markt + +1: kkolinko, markt, rjung -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1721 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1561561 Blamelist: kkolinko BUILD FAILED: failed compile_1 sincerely, -The Buildbot
Re: Git
Gradle is becoming the standard build tool for android. I didn't like it at first - I don't really see the point of groovy - but it's still better than 'programming' in ant, and you don't have to touch any XML. You can use any ant task from gradle - best to think of it as a non-xml ant file, with reasonable defaults and less typing for the most common operations. Git is best. Costin On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat wrote: > 2014/1/21 Yoav Shapira > > > Also +1 to separating the git vs svn discussion from the build system > > discussion (Maven, Ant, whatever.) (Side note: been using gradle > > recently, fun.) > > > > +1 > > Never used that Gradle yet though. > > Rémy >
Re: Using HttpParser for Cookie header?
On Jan 20, 2014, at 1:57 PM, Mark Thomas wrote: > Signed PGP part > On 20/01/2014 21:38, Jeremy Boynes wrote: > > I started to look at using HttpParser for the Cookie header but > > there are some differences in the way it works compared to the > > existing parser in Cookies that I wanted to check direction before > > getting too far in. > > > > The area I’m concerned about is the need to copy the bytes in > > order to parse the header. The Cookies parser relies heavily on > > MessageBytes and avoids copying to a String as far as possible. > > HttpParser, however, operates on a StringReader which requires > > converting to a String before parsing. > > > > After digging into the usage of Cookies I think there are only two > > places that read them: 1) Request#getCookies(), which needs to > > copy to Strings anyway in order to create the Cookie instances it > > returns 2) CoyoteAdapter#parseSessionCookiesId(), which parses the > > header and compares names as MessageBytes, only allocating a String > > for the value if the session cookie is found > > > > It’s this second one that has me concerned about switching to > > HttpParser as this gets called for every request. If we switch > > then there is going to be allocation and copying of the header that > > we currently don’t do. > > I share your concern. Worst case, we'll need to do a specific > MessageBytes based parse just for the session cookie. Assuming that > the session cookie name and value will remain US-ASCII (see no reason > why this should not be the case), we could get away with this as long > as we are mindful that there might be some UTF-8 we need to skip over. I started implementing this and a patch can be found here: http://people.apache.org/~jboynes/patches/0013-Start-of-a-more-lenient-RFC6265-cookie-parser.patch The best illustration of how it is parsing is probably the test cases. The main difference is that it does not apply RFC2109 rules unless $Version=1 is specified and because of that I did not end up using as much of HttpParser as I’d hoped. I believe the implementation handles correctly formatted headers according to the rules from Netscape, RFC2109 and RFC6265. It is lenient with respect to malformed input, breaking the header down into pairs separated by semi-colons (allowing for RFC2109 quoting/escaping where applicable) and attempting to accept each pair in isolation. If an individual pair is invalid (e.g. contains disallowed characters), it defaults to accepting that rather than dropping the cookie. The only cookies that actually get dropped are ones that do not specify a name or ones where Cookie’s constructor throws an IAE on the name. What this means is that an application will see every cookie Cookie will allow, making it symmetrical, but it will not see cookies whose names the Servlet spec configuration (i.e. STRICT_NAMING) would disallow. I kept the de-quoting behavior with one difference: for V0 cookies, RFC6265 quoting rules are applied which means any escapes are not undone. IOW for V0 «"a\bc"» will be returned as «a\bc» whereas for V1 it would be returned as «abc». I’m not convinced this is useful and it may be more predictable for users if we simply returned the actual value, quotes and all, by default with a config option to enable unquoting for V1 values only (perhaps the same option as would enable alternative G1a). Feedback welcome, ideally in the form of a test case showing what should be returned for a header text input. Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
