Ignore Range header when the method is different than GET

[laurenceisla]

Closes #2705

• Ignore Range header when method is different than GET
• Add/modify tests
• Refactor/clean code
• Add changelog

[laurenceisla]

My current approach is based on this convo which led to the conclusion that we should disallow the Range header altogether for mutation requests (mostly for POST requests).

Now, I have a doubt with what the RFC mentions:

A server MUST ignore a Range header field received with a request method that is unrecognized or for which range handling is not defined. For this specification, GET is the only method for which range handling is defined.

I understand that "ignore" means we could continue the request as if the header wasn't there? But it could be argued that we do define Range handling by returning a 400 status like we do with PUT and now, in this PR. Or am I wrong in any of those cases?

[steve-chavez]

My current approach is based on #2156 (comment) which led to the conclusion that we should disallow the Range header altogether for mutation requests (mostly for POST requests).

Agree.

A server MUST ignore a Range header field received with a request method that is unrecognized or for which range handling is not defined. For this specification, GET is the only method for which range handling is defined.

Agree as well. MUST for RFCs mean it's REQUIRED, so we should follow that behavior.

Really Range is quite broken even now at the master version. Which reminds me of #2204, we should also merge that one for this release and label the breaking change.

So yes, Range should be ignored for anything besides GET. The ?limit/offset thing can behave differently.