W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Byte ranges

From: John Franks <john@math.nwu.edu>
Date: Tue, 2 Jun 1998 09:23:48 -0500 (CDT)
To: Dave Kristol <dmk@bell-labs.com>
Cc: John Franks <john@dehn.math.nwu.edu>, http-wg@cuckoo.hpl.hp.com, Alex Rousskov <rousskov@nlanr.net>
Message-Id: <Pine.LNX.3.96.980602091830.2062A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/157
On Tue, 2 Jun 1998, Dave Kristol wrote:

> 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.
> 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.

You understand the problem correctly.

I don't think that RFC is specific.  There is no discussion of CRLF.
It gives an example in which all CRLF's are invisible and that is all.
I personally would not want to draw conclusions based on the number of
blank lines in the formating of the spec document! I don't think it is
sufficient to just refer to a MIME RFC either.

I don't care how it is done, but we need to be more precise.

John Franks
Received on Tuesday, 2 June 1998 07:25:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC