End of file can be lost if the requested range exceeds the file length

[countingpine]

I have found this problem in the wild on a 20i web host.

On the 20i CDN, it seems that for paths that end in "streamable" extensions (e.g. \.mp3$, \.wav$) which are handled by PHP (e.g. rewritten in .htaccess), HTTP requests will always be split up behind the scenes into ranges of whole megabyte-sized blocks (e.g. bytes=0-1048575, bytes=1048576-2097151).

The smartReadFile function uses these values as given for $begin and $end, and the Content-Length will be based on these.

But for the final block, if it's not a whole megabyte, then the fread loop will go past the end of the file, less data will be returned than expected from the Content-Length, and 20i will return nothing for this block.

The effective result is that the amount of data received will be rounded down to the nearest whole megabyte.

I think this can be fixed simply by ensuring the $end value is only updated if the new value is lower than the original ($size - 1).

I can submit a pull request for this if that would be helpful, but PHP is not my most fluent language.