> > 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