On Tue, Dec 3, 2024 at 8:21 PM Konstantin Kolinko <knst.koli...@gmail.com> wrote: > > вт, 3 дек. 2024 г. в 18:46, <ma...@apache.org>: > > > > This is an automated email from the ASF dual-hosted git repository. > > > > markt pushed a commit to branch main > > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > > > > The following commit(s) were added to refs/heads/main by this push: > > new 19efe70c87 Reject Range-Request if those ranges are not strictly > > in ascending order (#791) > > 19efe70c87 is described below > > > > commit 19efe70c8732f78803b9cff9be0a63c8f6202a8a > > Author: Chenjp <ch...@msn.com> > > AuthorDate: Tue Dec 3 23:44:32 2024 +0800 > > > > Reject Range-Request if those ranges are not strictly in ascending > > order (#791) > > > > * Reject Range-Request if those ranges are not strictly in ascending > > order > > > > request ranges are not strictly in ascending order, indicates either a > > broken client or a deliberate denial-of-service attack > > --- > > .../apache/catalina/servlets/DefaultServlet.java | 22 > > +++++++--------------- > > .../servlets/TestDefaultServletRangeRequests.java | 3 +++ > > 2 files changed, 10 insertions(+), 15 deletions(-) > > > > diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java > > b/java/org/apache/catalina/servlets/DefaultServlet.java > > index 25c8426ba3..62211b98f6 100644 > > --- a/java/org/apache/catalina/servlets/DefaultServlet.java > > +++ b/java/org/apache/catalina/servlets/DefaultServlet.java > > @@ -1240,7 +1240,7 @@ public class DefaultServlet extends HttpServlet { > > } > > > > private static boolean validate(Ranges ranges, long length) { > > - List<long[]> rangeContext = new ArrayList<>(); > > + long prevEnd = -1; > > for (Ranges.Entry range : ranges.getEntries()) { > > long start = getStart(range, length); > > long end = getEnd(range, length); > > @@ -1249,21 +1249,13 @@ public class DefaultServlet extends HttpServlet { > > return false; > > } > > // See https://www.rfc-editor.org/rfc/rfc9110.html#status.416 > > - // No good reason for ranges to overlap so always reject > > - for (long[] r : rangeContext) { > > - long s2 = r[0]; > > - long e2 = r[1]; > > - // Given valid [s1,e1] and [s2,e2] > > - // If { s1>e2 || s2>e1 } then no overlap > > - // equivalent to > > - // If not { s1>e2 || s2>e1 } then overlap > > - // De Morgan's law > > - if (start <= e2 && s2 <= end) { > > - // isOverlap > > - return false; > > - } > > + // No good reason for ranges to overlap or not listed in > > ascending order, so always reject > > + if (prevEnd < 0 || prevEnd < start) { > > 1.It is known that "start < 0" is false (i.e. 0 <= start), thus it is > enough to just check "(prevEnd < start)" here. > > > + // first range entry or strictly greater than previous > > range entry. > > + prevEnd = end; > > + } else { > > + return false; > > } > > - rangeContext.add(new long[] { start, end }); > > } > > return true; > > } > > 2. I think that overall this feature does not follow from rfc9110. > > rfc9110.(14.2 Range) says " or a set of many small ranges that are not > listed in ascending order," > > Note the "many" part. > > After some search, I found real-life examples of non-ascending ranges, > but they all are 10+ years old. They are valid ones, but I wonder > whether they are applicable nowadays. > > That was the time when PDF were displayed via "Adobe PDF Plugin" from > within browsers. (I think that the browser APIs that allowed such > plugins have already gone, as well as that plugin.) > > I think that the idea is that when a big file has some important > section at the end, it makes sense to request and receive that > specific small part first, before receiving other parts of the file. > > Trying to search for examples, > > https://stackoverflow.com/questions/1817750/do-most-browsers-make-multiple-http-requests-when-displaying-a-pdf-from-within-t/1818770#1818770 > "Do most browsers make multiple HTTP Requests when displaying a PDF > from within the browser" > > Range: bytes=242107-244329, 8060-76128 > > And finally Google found the following, our own: > https://bz.apache.org/bugzilla/show_bug.cgi?id=53814 > > Range: bytes=3446021-3447865, 475136-1792507 > > 3. Other thoughts, > a) Nowadays there is a name for technology: "PDF Linearization" or > "Fast Web View". > https://developer.adobe.com/document-services/docs/overview/pdf-embed-api/howtos/#pdf-linearization > > It mentions range requests, but I do not know whether those are > single-range requests, or multi-range requests. > > b) pdf.js (the PDF viewer used in Firefox and others) uses range requests: > https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#range > > but looking at the code, I think those are single-range requests. > https://github.com/mozilla/pdf.js/blob/master/src/display/network.js#L55 > > > In general, I wonder how often multi-range requests are used nowadays.
It was a pdf thing back then, I remember that. +1 for reverting however, since it's best to support what is allowed. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
