URLRequestFileJobs support range requests.  They also support automatically decompressing svgz files.  Range requests don't support compression.  Basically, if we ever see a range request for an svgz file, the results will be weird.  If the first byte we read from is not byte 0, we'll read from the middle of the file, attach a gzip filter to it, and it will fail to decompress the response.  If the first byte is byte 0, then it will successfully decompress the first however many bytes (Which is weird, as we'll be returning more than the number of bytes requested), but the last compressed byte we read will probably only be partially decompressed, and we'll return some error.  We'll also be reporting the wrong content_length, I suspect, if we don't just report -1 for all file URLs.

This doesn't seem like a huge issue, but it's one of the problems with pretending an svgz has a transfer-encoding, when they really have content-encodings.