On 03/12/2024 21:30, Rémy Maucherat wrote:
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
<<snip/>
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.
I will revert. Also, having re-read 14.2, the overlapping ranges check
needs to be relaxed to allow up to 2 overlapping ranges. Not sure how I
missed that given the number of times I have read that paragraph in the
last few days.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
