HTTP 407's, Byteserving and Chrome.

HTTP 407's, Byteserving and Chrome.

James McLean -
回帖数:1

Hi Folks,

We've seen a recent flurry of errors on our Moodle system, where a user agent attempts to download a file when the user is not logged in.

All the attempts are from a single user, each minute there are around 20 requests - spaced out at around 5 seconds between each request. I have some degree of confidence this usage pattern is a 'web accelerator' or similar browser plugin, rather than being malicious or an actual user.

When the request itself fails the client receives a 407 error from Moodle which I've traced back to:

https://github.com/moodle/moodle/commit/f22f1cafd254fef1dcf78fcd5007a1533baffb75

I am able to reliably reproduce the request/response using Fiddler which returns the 407 with any request containing range parameters for users who are not logged in, not just for PDFs as the commit message implies. We have seen Firefox UA and Chrome UA (specifically the coc_coc Vietnamese browser, which includes a web accelerator of sorts according to their documentation) generating these requests.

As I've only been able to manually complete the 407 error for an individual request, the best guess I have at the moment is that whatever the accelerator the client is using sees the 407 and is then simply retrying (and retrying, and retrying...) and eventually reaching some kind of time out in the client after 14000 or so errors.

I can't help but think the correct (or a better) HTTP header should be sent when the require_login_exception is thrown for example rather than handle it poorly inside fatal_error() as the correct http response code could actually help clients such as this detect they should not retry the request.

Has anyone noted any similar behaviour and could perhaps offer any suggestions? 

回复James McLean

Re: HTTP 407's, Byteserving and Chrome.

Howard Miller -
Core developers的头像 Documentation writers的头像 Particularly helpful Moodlers的头像 Peer reviewers的头像 Plugin developers的头像

Yes - we've seen the same. Almost exclusively from IP addresses in China (make your own mind up about that). 

We did do some fiddling around with byteserving but it didn't make a huge difference. We just block the IP addresses (or subnets) now.