Oleg,
Attached is a first draft for a patch against 5.0 to make the
Multipart stuff more applicable for those people who don't want
multipart/form-data. What would be the next stage to progress this?
On Sun, 2 Jun 2019 at 11:23, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> 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
>
--
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
