[GH-ISSUE #2018] Mobile client file uploads are missing the Content-Type header in the MultipartFormDataContent. #126741

Closed
opened 2026-06-13 18:31:47 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @BlackDex on GitHub (Jul 30, 2022).
Original GitHub issue: https://github.com/bitwarden/android/issues/2018

Steps To Reproduce

This isn't an actual issue with the Bitwarden servers, but more with the Vaultwarden servers.
That said though, I think the issue I'm going to describe should be fixed, since this will be more RFC complaint, and it will bring the mobile clients to match all other clients which do work correctly.

During a file upload which happens here: https://github.com/bitwarden/mobile/blob/f0ebc5e644453f9d2fa47de002451c5afe713a13/src/Core/Services/BitwardenFileUploadService.cs#L19

It creates a new MultipartFormDataContent but it does not add Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/octet-stream") to tell the receiving server that the data is an octet-stream. All the other clients seem to correctly send this header within the Multipart Boundary, but the Mobile client does not.

cli:

----------------------------912273455857274694771742
Content-Disposition: form-data; name="data"; filename="2.Fs5equeDmj6fyIUaXUcshg==|GrI8mEOTFZvQ2jLUUhMdHVRN2lLXCaWwVNMLSqsf1mw=|Zvz3r6rf/bxzQI1menhmWxbWoOSB9muLXPcTgsvt9zY="
Content-Type: application/octet-stream

...binary-data...

mobile:

----BWMobileFormBoundary637944497908437220
Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D

...binary-data...

Expected Result

mobile:

----BWMobileFormBoundary637944497908437220
Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D
Content-Type: application/octet-stream

...binary-data...

Actual Result

mobile:

----BWMobileFormBoundary637944497908437220
Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D

...binary-data...

Screenshots or Videos

No response

Additional Context

If i were able to create a PR i would, but all the stuff needed to build/compile/test and the knowledge on this language is a bit to much ;). And I would rather leave it to the experts here. I think this is a very small change for someone who has the knowledge.

Operating System

Android, iOS

Operating System Version

No response

Device

No response

Build Version

Version: 2022.6.2 (4851)

Beta

  • Using a pre-release version of the application.
Originally created by @BlackDex on GitHub (Jul 30, 2022). Original GitHub issue: https://github.com/bitwarden/android/issues/2018 ### Steps To Reproduce This isn't an actual issue with the Bitwarden servers, but more with the Vaultwarden servers. That said though, I think the issue I'm going to describe should be fixed, since this will be more RFC complaint, and it will bring the mobile clients to match all other clients which do work correctly. During a file upload which happens here: https://github.com/bitwarden/mobile/blob/f0ebc5e644453f9d2fa47de002451c5afe713a13/src/Core/Services/BitwardenFileUploadService.cs#L19 It creates a new `MultipartFormDataContent` but it does not add `Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/octet-stream")` to tell the receiving server that the data is an octet-stream. All the other clients seem to correctly send this header within the Multipart Boundary, but the Mobile client does not. cli: ``` ----------------------------912273455857274694771742 Content-Disposition: form-data; name="data"; filename="2.Fs5equeDmj6fyIUaXUcshg==|GrI8mEOTFZvQ2jLUUhMdHVRN2lLXCaWwVNMLSqsf1mw=|Zvz3r6rf/bxzQI1menhmWxbWoOSB9muLXPcTgsvt9zY=" Content-Type: application/octet-stream ...binary-data... ``` mobile: ``` ----BWMobileFormBoundary637944497908437220 Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D ...binary-data... ``` ### Expected Result mobile: ``` ----BWMobileFormBoundary637944497908437220 Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D Content-Type: application/octet-stream ...binary-data... ``` ### Actual Result mobile: ``` ----BWMobileFormBoundary637944497908437220 Content-Disposition: form-data; name=data; filename="2.G1wXKOe1mvSACgYFeXT/LQ==|DbAd+b/BsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE=|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw="; filename*=utf-8''2.G1wXKOe1mvSACgYFeXT%2FLQ%3D%3D|DbAd+b%2FBsuRQHekNw0eloE4cTsfBNGBPJrRLPYKaSRE%3D|AqrrCG0fWdZqLuG9uUFzGYNfES2HzqugRdNE7BKRdFw%3D ...binary-data... ``` ### Screenshots or Videos _No response_ ### Additional Context If i were able to create a PR i would, but all the stuff needed to build/compile/test and the knowledge on this language is a bit to much ;). And I would rather leave it to the experts here. I think this is a very small change for someone who has the knowledge. ### Operating System Android, iOS ### Operating System Version _No response_ ### Device _No response_ ### Build Version Version: 2022.6.2 (4851) ### Beta - [ ] Using a pre-release version of the application.
GiteaMirror added the buggood first issue labels 2026-06-13 18:31:49 -05:00
Author
Owner

@dbosompem commented on GitHub (Aug 16, 2022):

Hi @BlackDex ,thank you raising this issue. A PR has been opened, and hopefully once reviewed and successfully merged it resolves this.

<!-- gh-comment-id:1217014706 --> @dbosompem commented on GitHub (Aug 16, 2022): Hi @BlackDex ,thank you raising this issue. A PR has been opened, and hopefully once reviewed and successfully merged it resolves this.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#126741