On Thu, 2004-06-10 at 21:07, Karr, David wrote: > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > > > MultipartPostMethod can only produce 'multipart/form-data' > > encoded content, hence the content type header. > > > > HttpClient is intended/supposed to be content agnostic > > (MultipartPostMethod being the only (rather unfortunate) > > exception to this rule). You'll have to use another library > > to produce mime-encoded content such as attachments. > > That's unfortunate. Is there any plan to make this more flexible in > 3.0?
Well, there are certainly plans to make it "less flexible" by factoring out 'multipart/form-data' logic and moving in to a general purpose mime library. We ought not to try to transform HttpClient into a mime-library, browser or a vacuum cleaner. HttpClient should stay what it is, just a HTTP transport library. This said, HttpClient 3.0 is already dependent on Commons-Codec which is quite likely to provide some sort of mime encoding capabilities in the future Oleg > > > On Thu, 2004-06-10 at 19:41, Karr, David wrote: > > > I'm doing some testing of some web service constructs. I'm > > trying to > > > build a SOAP request with an attachment. If I directly use > > the SAAJ > > > api to build the object, and then stringify it, I see the result is > > > MIME-encoded, with a content-type for the main body of > > "text/xml", and > > > the attachment is whatever it's content type is, either > > "text/xml" or > > > blank. This is groked by my web-services runtime. > > > > > > I'm now trying to build the same HTTP request with > > HttpClient (using > > > 2.0 for now). I first built a simple test just using "PostMethod" > > > (not testing attachments yet). This works fine. It > > allowed me to set > > > the content-type header of "text/xml". > > > > > > Now, to test attachments, I would assume I have to use > > > MultipartPostMethod. This presents a problem. I tried to set the > > > "Content-Type" of the request to "text/xml", but I'm > > guessing this was > > > ignored, because this ended up being "multipart/form-data". > > > > > > I'm sure I'm misunderstanding something about how to build a proper > > > mime-encoded request, but I'm not sure what that is. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
