Line break should be CRLF, not LF.

[ivanovevgeny]

When requesting with 'form-data' PostMan send LF as linebreak and error happen:
"Unexpected end of MIME multipart stream. MIME multipart message is not complete" exception while parsing multipart form.

[abhijitkane]

Are you facing this with any POST/PUT requests made with form-data, or is there a particular URL/set of values that throw this error?

[ivanovevgeny]

I'd been testing my API with POSTMan and tried to POST files, but i had got an error "MIME multipart message is not complete". When I do it with Fiddler, POST complete succesfull.

[abhijitkane]

Can you give a sample URL on which this occurs, or a video of this problem?

I ran the following collection - https://www.getpostman.com/collections/1a031679183d03761670 , which uses form-data, and sends two form values, and a file, and it worked fine. Load the collection into Postman, replace test.csv with a file from your machine, and see if the error occurs.

[ivanovevgeny]

1. Doing request with POSTMan
   https://www.dropbox.com/s/si1ksl3oa7y1e8d/1.png?dl=0

Get an error: "ExceptionMessage": "Unexpected end of MIME multipart stream. MIME multipart message is not complete."

2. See our request in fiddler
   https://www.dropbox.com/s/ies2h2ttus1pgtr/2.png?dl=0

See that lacks CR character.

If correct body request in fiddler, request is executed correctly.

[abhijitkane]

If you're uploading a file, you should use the 'form-data' mode, not the raw mode. The form-data mode has an option of uploading files.

[ivanovevgeny]

Ok! It works! Sorry for your time spent.

But why not make CRLF as line break in raw mode?

[a85]

Line endings are OS dependent hence we don't change what is present. In most cases this does not matter. We have the form-data and binary modes for uploading files so should satisfy all use cases.

[sraka1]

This doesn't seem ok. Why so? Because, looking at the HTTP/1.1 spec here, one can clearly see that HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.

Then, checking out section 3.7 of the same spec, CRLF is always (!!!) a valid newline character, however in some cases a CR or LF alone are permitted.

Quick excerpts:
3.7.1
`When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).``

3.7.2 - multipart
The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts.

I believe that you should change the behaviour to conform with the HTTP spec.

[dertz]

I am looking at a response that I know has CRLF in it yet when displayed under the raw response I am not seeing them. This is confusing and leads one to believe that they are missing in the response. When I go to other tools that display the raw response I see them shown as line separators.

I tried the Response (formatted) tab but it is not displaying anything, the display area is blank. The response media type is text/csv. The link address for the formatted response tab is chrome-extension://ecjfcmddigpdlehfhdnnnhfgihkmejin/index.html#tabs-formatted. Not sure if it is looking for tabs and that is why it is not displaying anything. If the line separators showed up in the under formatted tab that would be helpful and acceptable.

[abotalov]

From https://tools.ietf.org/html/rfc7231 ("Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content")

An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.... This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the payload body (e.g., header fields).

The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts.

[JAnderson1122]

@abotalov I believe the section you quoted goes on to say:

This flexibility
regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload body (e.g.,
header fields).

The following section goes on to say:

3.1.1.4. Multipart Types

MIME provides for a number of "multipart" types -- encapsulations of
one or more representations within a single message body. All
multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts.

I believe what Postman should do is to convert all LF to CRLF, at least when using the 'raw' option for the request body.

[madmax911]

Cool program! I have a soft of similar issue though. I'm running the linux client and looking to intentionally put a CRLF into a raw post body but just because of OS differences I have no way to type/paste in exact text into the window. It seems to auto-change intentional CRLF's into just LF's. I think it would be convenient if they could be escaped in some way -- eg. \r\n - like a sort of 3rd option raw-escapable that would allow all the escape codes you would expect of a string in JS. Or maybe some way to set rules like to treat enter as CRLF vs LF.

This might satisfy some other people's concerns mentioned above.

[madmax911]

Cool program! I have a soft of similar issue though. I'm running the linux client and looking to intentionally put a CRLF into a raw post body but just because of OS differences I have no way to type/paste in exact text into the window. It seems to auto-change intentional CRLF's into just LF's. I think it would be convenient if they could be escaped in some way -- eg. \r\n - like a sort of 3rd option raw-escapable that would allow all the escape codes you would expect of a string in JS. Or maybe some way to set rules like to treat enter as CRLF vs LF.

This might satisfy some other people's concerns mentioned above.

Ok, I think I just solved my own issue -- in this post:
#4808 (comment)