We seem to have a wide variety of beliefs about how Content-Length
and boundary strings interact when a part of a multipart/* contains a
Content-Length. I prefer the behavior described by the last
email in this series. But this exchange shows a lack of consensus.
Can we reach consensus, or this an email versus HTTP difference in
behavior?
I have summarized the differt opinions below.
The meaning of multipart is defined in the MIME specifications.
Content-Length isn't part of the multipart definition.
As such, it's only a comment, and should be ignored.
It is illegal to send content where the content-length and the boundary
string disagree. So one doesn't take priority over the other. A
recipient should signal an error if it detects that they are
different.
to his reply above
BH> If there is a Content-Length header with a value of n, can the program
BH> skip over n bytes without looking for an erroneous boundary-string
BH> within the n bytes?
I think that a careful program would use the content-length to
check the boundary-string, rather than vice versa. However,
"non-standard values are non-standard"; there's only so far
you should go in a standard saying what programs have to do when
confronted with non-standard input.
I agree with the first part but not the second.
If you see a content length the obvious thing to do is to avoid the
computationaly intensive check of each byte (yes O(1) is less than
anything Boyer-Moore can do and that is not subjective). You
hop straight to the boundary.
If you see a boundary marker ther, then its OK other wise you signal
an error.
Note that if there are additional boundaries within the content length
delimited block you don't see them.
So content length should take priority but you may in some cases be
able to detect an error.
>Senders that are at all uncertain about the length of the data should
>omit content-length and rely on the boundary alone.
Yep