[3.0] Remove default content-length header from MultipartStream class

[Procionegobbo]

Content-Length in multipart bodies is not necessary. As far as I can verify is not used in any browser or other HTTP client.

For reference

• Similar problems in java package okhttp: Drop the Content-Length header from multipart parts square/okhttp#7319
• stackoverflow question: https://stackoverflow.com/questions/54299044/remove-content-length-header-in-guzzle-multipart-request

[GrahamCampbell]

Thanks for sending this in. I wanna wait till 3.0.0 to make this change. There are some other arguably breaking changes to make at the same time as this.

[GrahamCampbell]

3.0.0 should be coming out this year, if I can find the time to work on it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions.

[marcogermani87]

I think this pull request is very important.

Some legacies system can't manage the "Content-Length" header into "multipart/form-data" boundary and cut off the request.

For reference see the RFC 7578 in section 4.8 wich specify:

4.8. Other "Content-" Header Fields

The multipart/form-data media type does not support any MIME header
fields in parts other than Content-Type, Content-Disposition, and (in
limited circumstances) Content-Transfer-Encoding. Other header
fields MUST NOT be included and MUST be ignored.

Older system are not compliant because not apply the MUST be ignore policy but on the other side this code non apply the MUST NOT be included policy.

[GrahamCampbell]

I don't disagree. A 3.0 release is still planned.

[marcogermani87]

I don't disagree. A 3.0 release is still planned.

Thanks, do you have an expected release date?

[GrahamCampbell]

No, not yet. I hope some time in the summer.

[GrahamCampbell]

I am likely to create a 3.0 branch in the next few days/weeks, and merge this, so you may be able to use an experimental 3.0-dev version for a bit if you want.

[marcogermani87]

I am likely to create a 3.0 branch in the next few days/weeks, and merge this, so you may be able to use an experimental 3.0-dev version for a bit if you want.

Yes, of course; after merge i can use the experimental 3.0-dev. Actually i've already overrided in my project Client.php and MultipartStream.php files for exclude the "Content-Length" and works well.

[marcogermani87]

Hi @GrahamCampbell, any news on this?

[GrahamCampbell]

This is for sure still planned for 3.0.0.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions.

[GrahamCampbell]

Not stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions.

[GrahamCampbell]

Not stale.

[Cristobal-M]

I'm experiencing a similar issue with a banking system. I couldn't figure out why it was returning a 500 error when using Guzzle, but not when sending a raw body with with curl.

Turns out the difference was that I wasn't setting the Content-Length header when using curl directly for each content.

For now, I'm working around it by using a custom StreamInterface and setting the boundary manually in the Content-Type header.