Context: we have some integration tests for our WebDAV client that use Tomcat-Embedded as the WebDAV server (using org.apache.catalina.servlets.WebdavServlet). I'm in the process of migrating tomcat-embedded from 7.0.x to 9.0.x, and one of the tests is about resume support, i.e. uploads the same file multiple times, with each time the file growing in size. For this the client uses the Content-Range header. This test fails with all supported versions of Tomcat (8.5.x, 9.0.x and 10.0.x) because of a regression introduced during a refactoring (commit d1f58003a97af79df452cdbe5e94052acc4b7188 on the 9.0.x branch on GitHub). The Content-Range parser fails to parse headers of the form Content-Range: bytes 42-1233/1234 and so the org.apache.catalina.servlets.DefaultServlet.parseContentRange(HttpServletRequest, HttpServletResponse) method send a code 400 as response. Looking at the ContentRange.java code, it expects the following form: bytes=42-1233/1234 (note the "=") At first I thought that this might be a change in the Content-Range specification or some ambiguity in the specification (as our client code has successfully submitted such requests for a long time to Apache Web server's WebDAV module). However, the two RFCs where I found references to the Content-Range header both state that the correct form doesn't have an equal sign : https://datatracker.ietf.org/doc/html/rfc7233#page-12 https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Pull request for the main branch: https://github.com/apache/tomcat/pull/449 This fixes the problem on my tests (tested on the 9.0.x branch, which is the one I use in my project). Should I create a pull request for each branch ?
No need for multiple PRs. If the PR is accepted, it will be merged to whichever branch and then cherry-picked to the other branches.
Thanks for the report, PR and analysis. Good quality bug reports like this are always appreciated. Fixed in: - 10.1.x for 10.1.0-M6 onwards - 10.0.x for 10.0.12 onwards - 9.0.x for 9.0.54 onwards - 8.5.x for 8.5.71 onwards