Repeated .PDF byte range retrival loops, waaay excessive
Reported by
tinajaquest@gmail.com,
Jul 7
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Example URL: 37.17.45.124 - - [07/Jul/2018:13:59:50 -0400] "GET /ebooks/rtlcb.pdf HTTP/1.1" 206 65536 "https://www.tinaja.com/ebooks/rtlcb.pdf" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" Steps to reproduce the problem: 1. Only happens rarely 2. Above log entry is one example. 3. No idea how to cause the loops. What is the expected behavior? In attempting to download any of several of our ebooks, a loop 206 results, racking up thousands of sequential hits and creating denial-of-service issues. Most other users download normally and just fine. What went wrong? Happens severely about every week. Occasionally may happen more minor daily. Typically associated with a byte range of 16384 or 65536. I usually block the culprit with .haccess after 30,000 or so sequential hits. One of several subject problem files is https://www.tinaja.com/ebooks/rtlcb.pdf For most people most of the time, it downloads in the expected manner. Fatcow was unable to suggest a solution. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: 10.0 Flash Version: Fatcow gets pissed when response spikes. They deny any byte range issues. I'm fairly sure this is not content file specific and is in fact some sort of bizarre byte range pdf looping bug. You can reach me via don@tinaja.com or 928 428-4073.
,
Jul 9
,
Jul 9
It would be good to better understand what the access pattern looks like. For an instance of this problem with single IP address accessing one particular PDF, can you paste the first and last 3 log entries and mention how many repeated log entries are in the middle? e.g. 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... [repeat line 3 N times] 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... 1.2.3.4 - - [date] "GET /ebooks/rtlcb.pdf HTTP/1.1" $code $length ... BTW, there are browser extensions that implement PDF viewing or downloading capabilities. So there exists a possibility that some extension, and not the built in PDF Viewer, is doing this.
,
Jul 10
Thanks for filing the issue. @Reporter: As per comment# 3 could you please try as per comment# 3 and respond back to it. Hence adding Needs-Feedback label to it. Thanks!
,
Jul 13
Hello, We've got the same kind of behaviour on some of our sites. The log lines may not be sorted correctly, they came from load balanced reverse proxies 1.2.3.4 - - [12/Jul/2018:18:03:22 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 200 6122344 "https://www.google.be/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [12/Jul/2018:18:03:26 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 304 - "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [12/Jul/2018:18:03:26 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 206 617157 "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [12/Jul/2018:18:03:27 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 206 655360 "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [12/Jul/2018:18:03:28 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 206 19070976 "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [12/Jul/2018:18:03:49 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 304 - "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.839.190 requests later: 1.2.3.4 - - [13/Jul/2018:11:36:23 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 304 - "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [13/Jul/2018:11:36:24 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 304 - "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be 1.2.3.4 - - [13/Jul/2018:11:36:24 +0200] "GET /ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf HTTP/1.1" 304 - "https://www.mouscron.be/ma-ville/administration/urbanisme-amenagement-territoire/pdf/rcureglement062016.pdf" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" www.mouscron.be It didn't seem specific to windows, we've got about 1.200.000 requests from osx some days ago. Different PDFs, different websites, different clients but it seem specific to Chrome 67
,
Jul 13
Have also suffered the same issue ramping up from version 66/67. The impact was very bad with numerous repeated Content-Range request loops. Now looking at blocking this with accept-Ranges: none for impacted browsers.
,
Jul 18
re: comment 5 - Do you know why the server responded initially with HTTP 200 and 6122344. Presumably the latter number is the number of bytes in the response. Is that the normal behavior for the server? I tried putting the PDF on my server and I got 200 and 23075510. Which is expected as that is the size of the file plus some headers. re: comment 6 - Are you saying this happens with Chrome 66 as well?
,
Jul 19
re: Comment 7 - Clarification - 67+ - Our temp solution is now in place and no more looping. The solution was for Chrome 67+ Only change the accept-Ranges header to none. This is not ideal but we dropped from 100K loops down to a handful.
,
Jul 19
It's possible that I caused this when I fixed bug 825829 . Specifically, r546551 may be triggering this. It is also possible that r567257 fixes this. But without a way to consistently reproduce this bug, it's hard to say for certain. It would be helpful to know what the web server is sending back in the Content-Length header, vs. what the actual content length is. Another data point of interest is what a good (normal) request looks like, compared to the bad example in comment 5.
,
Aug 20
No feedback was received in the last 30 days from the reporter, so archiving this issue. Please re-open or file a new bug if necessary. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 20
Just to check back on this issue, does it still happen with Chrome 69?
,
Sep 26
Issue 875207 has been merged into this issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susan.boorgula@chromium.org
, Jul 9