Skip to content

fix: http content headers not sent when using axios #8039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

OS-kepatotorica
Copy link
Contributor

@OS-kepatotorica OS-kepatotorica commented Jun 26, 2025

The headers were not being set correctly when CapacitorHttp is set. The missing headers were Content-Type and Content-Length.

Video: https://github.com/user-attachments/assets/482e3a3b-1e0e-43fc-8648-7ad65ad81b05

closes:#7579

@markemer
Copy link
Member

We use conventional commits, so the title of this should be something like fix: description of problem/fix

Copy link
Member

@markemer markemer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just need to fix the title.

@OS-kepatotorica OS-kepatotorica changed the title Feature/rdmr 210 http content headers not sent when using axios fix: http content headers not sent when using axios Jun 30, 2025
@OS-kepatotorica
Copy link
Contributor Author

We use conventional commits, so the title of this should be something like fix: description of problem/fix

Updated, thanks for the call out!

@OS-kepatotorica OS-kepatotorica marked this pull request as draft July 1, 2025 17:50
@OS-kepatotorica OS-kepatotorica marked this pull request as ready for review July 1, 2025 20:34
@jcesarmobile
Copy link
Member

I personally don't like this approach of setting the content-type ourselves.

First of all, this change affects both fetch and XHR, but fetch is working fine without this change.

Second, this change prevent's users from setting their own boundary since both headers get sent to the native code, the user provided one and the hardcoded one, and the native code sometimes picks the user provided one and other times it picks the hardcoded one.

Can at least be done only for XHR and check if the user provided a content-type header to not hardcode it in that case?

@OS-kepatotorica
Copy link
Contributor Author

I personally don't like this approach of setting the content-type ourselves.

First of all, this change affects both fetch and XHR, but fetch is working fine without this change.

Second, this change prevent's users from setting their own boundary since both headers get sent to the native code, the user provided one and the hardcoded one, and the native code sometimes picks the user provided one and other times it picks the hardcoded one.

Can at least be done only for XHR and check if the user provided a content-type header to not hardcode it in that case?

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants