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