#7 GET-MULTIPART-SEQUENCE returns too big a buffer
I'm not sure if this is a bug, but I suspect it may be.
If a segment of a multipart is retrieved by GET-MULTIPART-SEQUENCE, it appears it returns all bytes up to the beginning of the line that has the boundary string. I suspect it may be that it should return all bytes up to the CRLF just before the beginning of the boundary line.
In other words, if part of the input were
--BoundaryString
Content-type :text/plain
This is some text
--BoundaryString
I believe the body of this should be
"This is some text
"
and not be
"This is some text
"
Obviously, this depends upon the RFC on how the boundaries in multipart MIME work and I haven't fully researched them on this. But my reason for expecting this is that otherwise one could not pass text that doesn't end in a CRLF. So I want
--BoundaryString
Content-type: text/plain
This is some text
--BoundaryString
to return the text "This is some text" (rather than
"This is some text
").
To clarify: I was using :RAW T and my buffer's type was (UNSIGNED-BYTE 8). In my application, I'm actually using Content-type: application/octet-stream.
After some further investigation in the code, it appears that if I had used :RAW NIL, it would have worked as I expected (by not returning the newline from just before the boundary line).
I suggest that the (< leftoff ebuf) towards the end of the file be changed to (< leftoff eline). This may allow that whole (if* raw ...) expression to be simplified.
It appears this should be changed also inside the (>= dest end) clause, thus making no difference there whether raw is T or NIL.
We rewrote this code to support the international version of Lisp (where a char isn't the same
as an (unsigned-byte 8)).
If we're still getting any extra data in any mode please let me know.