On Sun, 2019-06-02 at 09:47 +0100, Adam Retter wrote:
> > > On my system that produces a HTTP Request like:
> > >
> > > POST / HTTP/1.1
> > > Content-Length: 456
> > > Content-Type: multipart/form-data;
> > > boundary=ZQwFLuoO6V1SFdqg2lI6DaVwlvKIZjj2Pb
> >
> > I can change this content-type by calling .setContentType() on the
> > entity builder,
>
> Ah yes! I forgot to include that, sorry.
>
>
> > however:
> >
> > > Content-Disposition: form-data; name="part1"
> >
> > Every part gets this content-disposition which is clearly bogus for
> > non-form multipart messages.
>
> I missed that somehow when I was checking the output. The closest I
> think you could get is to override the Content-Disposition in each
> part by using:
>
> addField("Content-Disposition", "inline")
>
> Whether you should use `inline` or `attachment` I cannot say, as I
> don't know enough about your use-case.
>
> Another option, which would be cleaner would be to to derive your own
> builder class from org.apache.http.entity.mime.FormBodyPartBuilder.
> Having studied the code of that class, it looks to me like it already
> does 95% of what you need, and you could just modify your version of
> the `build` method, to not do the Content-Disposition stuff.
>
> Whether that class stays stable over time I cannot say, I agree with
> you that it looks like the HTTP Client is missing an easy way to
> cleanly do multipart. It would seem to me that a
> org.apache.http.entity.mime.MultiPartBuilder would make sense, from
> which org.apache.http.entity.mime.FormBodyPartBuilder is subclassed.
>
> Cheers Adam.
>
Adam, Norman, et al.
12 years ago the plan was to use Apache Mime4j once its APIs got
frozen. The existing multipart code was initially intended as a throw-
away stop-gap fix.
It looks increasingly likely Mime4j 1.0 will never get released in our
life span, but it is still infinitely more useful and flexible than
what HttpClient has to offer.
Having said all that, there is still time to get onboard and fix
whatever you deem in need of fixing in 5.0. Time is running out,
though, as we are looking at freezing 5.0 APIs soon.
By the way, MIME spec refers to MIME headers as `header fields`, so the
choice of method names was not completely random.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
