fix: drop Content-Type: application/json preset so multipart uploads work#12
Open
ViT4RGh0ST wants to merge 1 commit into
Open
fix: drop Content-Type: application/json preset so multipart uploads work#12ViT4RGh0ST wants to merge 1 commit into
ViT4RGh0ST wants to merge 1 commit into
Conversation
…work
The client pre-set Content-Type: application/json on the shared PendingRequest
(and again in sendRequest and pool), which silently broke the file-upload flow
recommended in the README:
SapB1::sendRequestWithCallback(fn ($http) => $http
->attach('my_file', file_get_contents(...), 'file.pdf')
->post('Attachments2'));
Guzzle only applies its own `Content-Type: multipart/form-data; boundary=...`
when no Content-Type is already set (see GuzzleHttp\Client::applyOptions).
The preset kept `application/json` stuck on multipart requests, so SAP B1
Service Layer received a multipart body under a JSON content type and rejected
it with `BadFormat`.
Removing the preset is safe because Laravel's HTTP client already defaults
the body format to JSON and Guzzle conditionally sets the matching
Content-Type for JSON payloads — so normal CRUD calls still send
`Content-Type: application/json` as before. Accept: application/json is
preserved.
Adds a regression test covering the attach() + post() flow so the preset
doesn't creep back in.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The client pre-set
Content-Type: application/jsonon the sharedPendingRequest(and again insendRequestandpool), which silently broke the file-upload flow recommended in the README:Guzzle only applies its own Content-Type: multipart/form-data; boundary=... when no Content-Type is already set (see GuzzleHttp\Client::applyOptions). The preset kept application/json stuck on multipart requests, so SAP B1 Service Layer received a multipart body under a JSON content type and rejected it with BadFormat (code -1).
Why it's safe
Laravel's HTTP client already defaults the body format to json and Guzzle conditionally sets Content-Type: application/json when the request has a JSON body — so normal CRUD calls (post, patch, put) keep sending Content-Type: application/json as before. Accept: application/json is preserved.
Test plan
Added regression test: it sendRequestWithCallback supports multipart uploads without Content-Type collision
Full suite passes: 154 tests, 319 assertions
Pint + PHPStan clean