Open brndt opened 2 weeks ago
I think the cleanest way is probably this
FormField
Why not just use the headers in the codec? For content length / type?
@jdegoes this content type and length is part of the body, not the headers. We are talking about multipart
--BOUNDARY
Content-Type: application/json
Content-Disposition: form-data; name="job"
{
"object":"Contact",
"contentType":"CSV",
"operation":"insert"
}
--BOUNDARY
Content-Type: text/csv
Content-Disposition: form-data; name="content"; filename="content"
(Content of your CSV file)
--BOUNDARY—
Ah, multi-part.
Can we have direct support for Form
?
What I mean by that is, if a user needs to handle form data in a low-level way, accessing content-type and other settings, then perhaps the body type can be Form
, and they can implement
that, allowing them access to the raw details of the multi-part form.
This would also allow users to write generic code that can handle any multi-part forms.
@brndt Would that satisfy your need?
@987Nabil Thoughts?
What is not easy to do right now? Right now using HttpCodec.binaryStream doesn't allow you to pass the metadata such as content type and content length (amongst other stuff) to
implements
method. It would be great to have all the information that you have when working with the plain Binary FormField