вт, 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.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to