| Content-Type: image/gif
| Relative-URL: /foo/bar/blueball.gif
|
| [exactly 7001 bytes of binary data immediately following the CRLF.]
| --outermost
Aha! So it SHOULD be a CR LF to work (harking back to the CR LF discussion and
sorry I don't have the message id handy). If the server just sends LF, and the
client expects 2 bytes (CR LF) the first byte of the GIF might be skipped - or
the client would have to check its value. But the ASCII code for LF might be a
valid first byte for some image types - not GIF, I know.
At any rate, the CR LF problem needs to be brought to closure if we are going to
have binary encoding. You have to know exactly where to start counting.
-- Chris