Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[core] Implement new multipart design in core-client-rest #28971

Closed
timovv opened this issue Mar 19, 2024 · 0 comments · Fixed by #29047
Closed

[core] Implement new multipart design in core-client-rest #28971

timovv opened this issue Mar 19, 2024 · 0 comments · Fixed by #29047
Assignees
@timovv
Labels
Azure.Core Client This issue points to a problem in the data-plane of the library.
Milestone
2024-04

Comments

@timovv
Copy link
Member

timovv commented Mar 19, 2024

Implement new multipart API as described in this Loop (MS internal).

This involves a breaking change to core-client-rest and corresponding major version.
@timovv timovv added Client This issue points to a problem in the data-plane of the library. Azure.Core labels Mar 19, 2024
@timovv timovv self-assigned this Mar 19, 2024
@timovv timovv added this to the 2024-04 milestone Mar 19, 2024
@timovv timovv mentioned this issue Mar 25, 2024
Merged
1 task
timovv added a commit that referenced this issue Apr 25, 2024
@timovv
[core] New multipart/form-data primitive in core-client-rest (#29047)
8cd5bc2 
### Packages impacted by this PR

- `@azure/core-client-rest`

### Issues associated with this PR

- Resolves #28971

### Describe the problem that is addressed by this PR

- Major bump of `@azure-rest/core-client` to 2.0.0 due to introduced
behavioral breaking change.
- The expected body shape for `multipart/form-data` is now an array of
`PartDescriptor`, which has the following fields:
- `headers` and `body` representing the multipart request headers and
body
  - Convenience fields for MIME header values:
    - `contentType`, for the `Content-Type` MIME header
- `name`, `filename`, `dispositionType`, for constructing the
`Content-Disposition` MIME header
- These convenience values take precedence over any existing MIME
information (name and filename) present in the request body (i.e. the
`name` property on `File` and the `type` property on both `File` and
`Blob`)
- If the headers are set explicitly in the `headers` bag, the headers
bag value takes precedence above all.
- Implemented part serialization flowchart more or less as described in
the Loop, with a couple of notable differences (and other less notable
ones):
- `string` values are put directly on the wire regardless of content
type; this allows for customers to pass pre-serialized JSON to the
service
- If no content type is specified, and we cannot infer the content type,
we default to `application/json` (i.e. there is no situation where we
would throw a "cannot encode type" error)
- Added support for `FormData` objects. If a `FormData` object is
encountered, it is passed directly to `core-rest-pipeline` for it to
handle.

### Are there test cases added in this PR? _(If not, why?)_

Yes

### To do

- [ ] Port Core change to ts-http-runtime before merging
@github-actions github-actions bot locked and limited conversation to collaborators Jul 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@timovv timovv

Labels
Azure.Core Client This issue points to a problem in the data-plane of the library.
Projects
None yet
Milestone
2024-04
Development

Successfully merging a pull request may close this issue.

[core] New multipart/form-data primitive in core-client-rest timovv/azure-sdk-for-js
1 participant
@timovv