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

Re: Byte ranges

From: Alex Rousskov <rousskov@nlanr.net>
Date: Tue, 2 Jun 1998 15:36:00 +0100 (BST)
To: Dave Kristol <dmk@bell-labs.com>
Cc: John Franks <john@math.nwu.edu>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SGI.3.96.980602081149.734D-100000@Meta-Bug>
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:

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

That's correct. According to MIME, there also should be a <CRLF> before other
boundaries (2nd, 3rd, etc). However, the example is not detailed enough to
see if those <CRLF>s are there. 
 
> On the other hand, the purpose of the second CRLF is to ensure that the
> boundary occurs at the beginning of a line, 

I could understand why MIME cares about message "appearance". I see no reason
why HTTP should be human-oriented. Too late for that though :). 

> which we already know to be
> true for the first boundary in an HTTP response (and in email
> messages?).

Right, but to ease implementation (both generation and parsing) and to be
consistent, it would be much better if HTTP would explicitly require CRLF to
prepend _all_ boundaries rather than all but the first one. Alternatively,
HTTP could explicitly prohibit those extra CRLFs.
 
> To me it appears that RFC 2068 conflicts with RFC 2046 in its letter,
> but follows it in the spirit.

HTTP says nothing about CRLFs prepending the boundaries. Thus, it encourages
us to follow MIME specs. MIME requires CRLFs. However, the example in HTTP
does not follow MIME requirements. Since MIME contains a lot of requirements
that HTTP overwrites, it is not clear if the intention was to overwrite this
requirement as well or not. 

IMHO, HTTP should minimize references to MIME format and simply provide its
own BNF for multipart messages. Personally, I find "refer-to-MIME and
list-the-differences" approach error prone. Such an approach leads to
questions like "did they forget to list that difference?"... 

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

Thus, we already have two serves implementing multiparts differently: NW and
yours. :)

Thank you,

Alex.
Received on Tuesday, 2 June 1998 08:48:12 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:18 EDT