You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Guillaume Cottenceau <gc...@mnc.ch> on 2005/10/13 17:09:25 UTC
httpclient 3.0 & multipart/related content-type
Hi,
We use httpclient for quite some time now, and as we now use 3.0
I'm currently suppressing usage of deprecated methods/classes.
To implemented multipart/related content-type, we had a
MultipartRelatedPostMethod class inheriting from
MultipartPostMethod, thus in the light of new request entity
stuff I have created a MultipartRelatedRequestEntity inheriting
from MultipartRequestEntity.
But it is very frustrating to see that the only needed change
compared to MultipartRequestEntity is the content-type (the base
name is different, and it needs a start= parameter and an
optional type= parameter), but the way the mother class protects
its data makes it very difficult: the content-type needs the
multipart boundary, and getMultipartBoundary() is private (it
also needs the name of the first part, but the parts are
private); then duplicating this code creates another problem
because it needs the params (HttpMethodParams) which is also
private, and generateMultipartBoundary() which is also private.
In the end, I'm duplicating half the code of the mother class.
Would it be possible to consider moving the visibility of the
parts and getMultipartBoundary() from private to protected?
Don't hesitate to yell at me if there was an obvious solution
I've missed. I have found some on-topic information in the
archives[1] but I was unable to find the "multipart related code"
in 3.0-rc4.
I'm still not sure why official httpclient doesn't provide a
multipart/related implementation (with discussed visibility
changes, it's barely a 30-line class).
Thanks for your time.
[1] http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg02121.html
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: httpclient 3.0 & multipart/related content-type
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Oleg Kalnichevski <olegk 'at' apache.org> writes:
[...]
> > Would it be possible to consider moving the visibility of the
> > parts and getMultipartBoundary() from private to protected?
>
> Guillaume,
>
> Just file a bug report. There's no reason for those methods to be
> private
Ok.
[...]
> > I'm still not sure why official httpclient doesn't provide a
> > multipart/related implementation (with discussed visibility
> > changes, it's barely a 30-line class).
>
> We are trying to move away from having to maintain code that is either not
> strictly HTTP related (MIME, for instance) or requires too much of
> specialized expertise (NTLM, for instance). We just do not have resources
> to maintain such code properly and would very much rather use a
> specialized library maintained outside HttpClient
I see. I am too unexperienced with multipart/related to realize
that it was MIME when multipart/form-data was not.
> As far as multipart classes are concerned, we would like to factor them out
> and merge into Commons [Codec] at some point. Volunteers who could give us
> a helping hand with this task are very much welcome.
Thanks for your feedback.
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: httpclient 3.0 & multipart/related content-type
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Oct 13, 2005 at 05:09:25PM +0200, Guillaume Cottenceau wrote:
> Hi,
>
> We use httpclient for quite some time now, and as we now use 3.0
> I'm currently suppressing usage of deprecated methods/classes.
>
> To implemented multipart/related content-type, we had a
> MultipartRelatedPostMethod class inheriting from
> MultipartPostMethod, thus in the light of new request entity
> stuff I have created a MultipartRelatedRequestEntity inheriting
> from MultipartRequestEntity.
>
> But it is very frustrating to see that the only needed change
> compared to MultipartRequestEntity is the content-type (the base
> name is different, and it needs a start= parameter and an
> optional type= parameter), but the way the mother class protects
> its data makes it very difficult: the content-type needs the
> multipart boundary, and getMultipartBoundary() is private (it
> also needs the name of the first part, but the parts are
> private); then duplicating this code creates another problem
> because it needs the params (HttpMethodParams) which is also
> private, and generateMultipartBoundary() which is also private.
> In the end, I'm duplicating half the code of the mother class.
>
> Would it be possible to consider moving the visibility of the
> parts and getMultipartBoundary() from private to protected?
>
Guillaume,
Just file a bug report. There's no reason for those methods to be
private
> Don't hesitate to yell at me if there was an obvious solution
> I've missed. I have found some on-topic information in the
> archives[1] but I was unable to find the "multipart related code"
> in 3.0-rc4.
>
> I'm still not sure why official httpclient doesn't provide a
> multipart/related implementation (with discussed visibility
> changes, it's barely a 30-line class).
>
We are trying to move away from having to maintain code that is either not
strictly HTTP related (MIME, for instance) or requires too much of
specialized expertise (NTLM, for instance). We just do not have resources
to maintain such code properly and would very much rather use a
specialized library maintained outside HttpClient
As far as multipart classes are concerned, we would like to factor them out
and merge into Commons [Codec] at some point. Volunteers who could give us
a helping hand with this task are very much welcome
Oleg
> Thanks for your time.
>
> [1] http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg02121.html
>
> --
> Guillaume Cottenceau
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org