Re: Byte ranges

John Franks wrote:
> 
> I recently received the message below.  Looking at
> draft-ietf-http-v11-spec-rev-03 it seems the description
> of multipart/byteranges leaves a lot to be desired on the
> subject of where <CRLF> should occur.  Is there a definitive
> answer to this?
> [...]
> ---------- Forwarded message ----------
> Date: Mon, 1 Jun 1998 16:04:33 -0600 (MDT)
> From: Alex Rousskov <rousskov@nlanr.net>
> [...]
>         In implementing multipart range responses you probably followed RFC
> 2046 (prepending boundaries with <CRLF>). However, HTTP RFC (2068) gives an
> example where boundaries are _not_ prepended with <CRLF> (note that there is
> only one empty line after headers):
> 
>    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-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
> 
> [...]

I'd like to be sure I understand the question.  Please correct me if
I've got it wrong.

It appears that RFC 2046 (Sect. 5.1.1) treats the CRLF that precedes a
boundary as *part* of the boundary:

   The boundary delimiter MUST occur at the beginning of a line, i.e.,
   following a CRLF, and the initial CRLF is considered to be attached
   to the boundary delimiter line rather than part of the preceding
   part.
   [...]
   NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

In the example Alex cites, by RFC 2046, there should be two CRLFs in a
row:  1) to separate the HTTP response headers from the response body;
and 2) to precede (and be considered part of) the multipart boundary.  

On the other hand, the purpose of the second CRLF is to ensure that the
boundary occurs at the beginning of a line, which we already know to be
true for the first boundary in an HTTP response (and in email
messages?).

To me it appears that RFC 2068 conflicts with RFC 2046 in its letter,
but follows it in the spirit.  I think we need a MIME guru to pass
judgement.  Or we can add another note to Section 19.4 of the HTTP/1.1
spec. about this difference beteen HTTP and MIME.

(FWIW, the output from my server looks like the RFC 2068 example, with
one blank line between the HTTP response headers and the first
boundary.)

Dave Kristol

Received on Tuesday, 2 June 1998 07:30:26 UTC