add new EdgeThrottled exception

[mohamedhafez]

Edge throttles much more aggressively than other browsers, so I added a new ResponseError subclass called EdgeThrottled and added code to verify_response to distinguish this case from a generic ResponseError. I'd still like to know if I ever get throttled by Chrome, Firefox, or Safari since it's never happened before, but it happens so much with Edge that I've just given up and ignore these exceptions personally. Others may want to handle this specific case differently as well.

If this PR would be accepted, let me know and I'll write some tests for it

[collimarco]

In general I would prefer to avoid vendor-specific exceptions... We already have a TooManyRequests error for the "standard" 429 status code.

The 406 status code returned by Microsoft is plain wrong - see the definition here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406

I already reported this issue years ago in their bug trackers.

In any case I recommend to retry all unknown ResponseErrors (we do that), so defining a new type of error should be unnecessary.

[collimarco]

This issue has been going on for a very long time...

See all these related issues:

• Windows Push Notification Services: 406 Not Acceptable zaru/webpush#109
• Treat 406 from Microsoft as 429 zaru/webpush#103
• Windows Push Service returns wrong status code 406 instead of 429 MicrosoftDocs/windows-dev-docs#4166
• Windows Push Notification service (WNS) returns the wrong status code for rate limiting microsoft/WindowsAppSDK#3501

[mohamedhafez]

Personally I'd argue that if Edge has been doing this incorrectly for a very long time, they are unlikely to fix it any time soon, and we'd be better off dealing with the facts on the ground as opposed to what the spec says it should be...

[mohamedhafez]

I do agree with your statment here though:

This proposal is semantically wrong: you cannot catch a 406, which has a very specific meaning, and raise TooManyRequests . It may produce exceptions that are extremely confusing and hard to debug in the future, with other push services, or with future changes.

That's why i think it should be dealt with as a special case, specifically tailored to the one browser that's doing it wrong.

I personally don't wish to retry all unhandled ResponseErrors: I'd rather just be notified of them, decide what it is that we've been missing handling, and add the code to handle it correctly. Some errors it isn't appropriate to retry, like things that are our fault like PayloadTooLarge for example, and who knows if a new, unhandled exception is one of those. In this case specifically, you'd need special exponential backoff retrying for throttling errors or it would just make the problem worse.