> > 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 Retter
eXist Core Developer
{ United Kingdom }
a...@exist-db.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
