Fixing a couple of issues with HTTP-Range for static files

[augensalat]

Moin sri,

Mojolicious had some problems with certain HTTP-Range requests.
Here are my changes:

• fixed bug where a wrong Content-Length was calculated
  for Range requests on empty files
• fixed bug where a wrong Content-Length was calculated
  for swapped Range values
• do not silently ignore non-numeric value in Range
• support HTTP-Range for final bytes (Range: bytes -42)

[kraih]

And why is range support for empty files useful?

[kraih]

Also, which user agents actually use Range: bytes=-42?

[kraih]

In the future, please do not bundle multiple changes into a single pull request, unless they all have been discussed and accepted already, odds are the whole patch gets rejected because of a small subset.

[kraih]

Since handling range requests for empty files does not actually require additional code, i've just added it anyway. 6804499

[kraih]

Turns out a clean implementation is actually less code, that made the decision very simple. :)

[augensalat]

And why is range support for empty files useful?

Wrong question. M was pretending "Content-Length: 1" and returned 0
bytes, which was clearly a bug.

[augensalat]

Also, which user agents actually use |Range: bytes=-42|?

It's defined in RFC 2616 §14.35.1, therefore a server should handle it,
if possible.

[augensalat]

In the future, please do not bundle multiple changes into a single pull
request, unless they all have been discussed and accepted already, odds
are the whole patch gets rejected because of a small subset.

OK. Thank you.

[augensalat]

Turns out a clean implementation is actually less code, that made the
decision very simple. :)

from RFC 2616 §14.35.1

If the last-byte-pos value is absent, or if the value is greater than or
equal to the current length of the entity-body, last-byte-pos is taken
to be equal to one less than the current length of the entity- body in
bytes.

Your way doesn't handle that correctly atm.

[kraih]

It's defined in RFC 2616 §14.35.1, therefore a server should handle it, if possible.

That's not a good reason, there are many things in the RFCs around HTTP that don't really belong in the real world. For example we will never support multipart/byteranges.