Okhttp: Multipart should not add "Content-Length"

[TanTan-TT]

I found following request will cause server error
The body of your POST request is not well-formed multipart/form-data

--be1563be-4245-4ac5-8a95-498ba5b57ba8
content-disposition: form-data; name="name"
Content-Length: 22

ic_menu_white_24dp.png
...
--d4653e4a-9a5d-42e5-8a49-fcafbe9c673c
content-disposition: form-data; name="file"; filename="ic_menu_white_24dp.png"
Content-Type: image/png
Content-Length: 92

In okhttp code,

     long contentLength = body.contentLength();
      if (contentLength != -1) {
        sink.writeUtf8("Content-Length: ")
            .writeDecimalLong(contentLength)
            .write(CRLF);
      } else if (countBytes) {
        // We can't measure the body's size without the sizes of its components.
        byteCountBuffer.clear();
        return -1L;
      }

And I google the rfc1867, in the document, there is not description for adding "Content-Length", so maybe it is a bug for okhttp.

[JakeWharton]

Sounds like a server bug. Any number of headers are allowed in the part bodies so if the length isn't used it should simply be ignored or if it is used the number if accurate so the server is using it incorrectly.

[TanTan-TT]

@JakeWharton Are you sure for that? Because I did not found any content that content-length can be included in request in rfc1867

[JakeWharton]

It also does not forbid it. That RFC is just adds the 'form-data' subtype to the existing multipart type. The MIME RFC 1341 states:

The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields are generally to be ignored in body parts.

So while it's redundant with the part boundaries, the server software should not crash either.

[st0rm23]

some oss provider will require strict format of multipart/form-data while the okhttp will fail to pass.
the temporary solution is copying an own MuiltipartBody from source code and change following code:
if (contentLength != -1) {
sink.writeUtf8("Content-Length: ")
.writeDecimalLong(contentLength)
.write(CRLF);
} else if (countBytes) {
// We can't measure the body's size without the sizes of its components.
byteCountBuffer.clear();
return -1L;
}
to
if (contentLength != -1) {
} else if (countBytes) {
// We can't measure the body's size without the sizes of its components.
byteCountBuffer.clear();
return -1L;
}

all things will be ok

[JakeWharton]

Strict by whose definition? Per the RFC it's not forbidden and explicitly calls out that headers starting with "Content-" are allowed.

[st0rm23]

Sorry, maybe you are right. However, I think if we add something that the RFC not clearly defines, we'd better to create a option to turn it off. For example, it is not comfortable for most of people if we force to add a header named "Content-hello"

[JakeWharton]

I would agree, except Content-Length is widely known and used and offers
all kinds of advantages such as the ability to pre-size buffers when
reading individual parts.

On Thu, Feb 18, 2016, 8:20 PM Lin Binghui [email protected] wrote:

Sorry, maybe you are right. However, I think if we add something that the
RFC not clearly defines, we'd better to create a option to turn it off. For
example, it is not comfortable for most of people if we force to add a
header named "Content-hello"

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2138#issuecomment-186003145.

[swankjesse]

No action for us to take here.

[bpappin]

There most definitely is action for the okhttp team to take here.
The content length breaks systems that stream content and don't know the length, because the server sees a length of zero.

At the very least, we should be able to access the headers of the part.

[dilroop]

for my case content-length is being calculated wrong .. ignoring \n character (was 79 but should have been 80 )

[JakeWharton]

File a bug with a test case or executable sample that reproduces the problem

On Tue, Jun 18, 2019, 7:21 PM Dilroop SIngh [e-mail]
wrote:

for my case content-length is being calculated wrong .. ignoring \n
character (was 79 but should have been 80 )

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/2138?email_source=notifications&email_token=AAAQIEIRAX5DQWCQOJ6GCLLP3GJZDA5CNFSM4BXD2ASKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAPNAQ#issuecomment-503379586,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQIEI2EYMGPZX6LE6IYSDP3GJZDANCNFSM4BXD2ASA
.