Categories
Programming

RFC 7233: So Wrong

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:

  1. 500 (500-999) + 1000 (7000-7999) bytes of pure content
  2. 197 bytes of multipart boundaries and headers
  3. 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.