Consider allowing whitespaces after the boundary and before the CRLF

[Armiixteryx]

(This is a continuation of #24 )

Hello. I open this issue to ask if the following kind of boundary may be supported:

_(where the boundary is simple_boundary)_

This boundary ends with SPACE+CRLF.

Currently I get the following error when trying to parse a payload with that boundary:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: multer: Multipart stream is incomplete'

Is that kind of boundary standard compliant?

My current workaround is to make multer to process an arbitrary boundary, not ideal but will work meanwhile.

As a reference, I have tried multipart crate with a similar result, but Python request-toolbet processes that boundary without issues.

Thanks :)

[SergioBenitez]

Is that kind of boundary standard compliant?

Yes. According to RFC 2046 5.1.1:

The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF.

Specifically, we have:

; from RFC 2046
multipart-body := [preamble CRLF]
                  dash-boundary transport-padding CRLF
                  body-part *encapsulation
                  close-delimiter transport-padding
                  [CRLF epilogue]

dash-boundary := "--" boundary
                 ; boundary taken from the value of
                 ; boundary parameter of the
                 ; Content-Type field.

transport-padding := *LWSP-char

; from RFC 822
LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE

@jebrosen Given you were the last one to touch the parser, how do you feel about tackling this?