Do you remember that one time (about 10 minutes ago) where I started double-checking RFC 7233 to make sure I was doing everything perfectly, and found out that the RFC is WRONG? There’s a first time for everything.
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
After deep analysis (and lots of recalculations) I discovered that the RFC is incorrect and uses a wrong content length. Let’s sum it up:
- 500 (500-999) + 1000 (7000-7999) bytes of pure content
- 197 bytes of multipart boundaries and headers
- 11 CR+LF (22 bytes)
For a whopping total of 1719. What’s left? 22 bytes. Or, maybe best put, 11 CR+LF. They counted them twice.
Bonus fact: this multipart example is also INVALID and might be rejected from strict clients. A leading CR+LF is considered part of the boundary, so the first boundary in the content should be separated by three CR+LF and not two.