Just a few notes on the new multipart code: * I was a little surprised to see a hard-coded multipart boundary in there. The boundary is usually generated anew for each request, using random values. I'm not completely sure what kinds of problems this might cause. The only one I can think of is that if you *ever* have the boundary in the content, it will *always* fail. If the boundary is randomly generated, then if one attempt to post fails because the content contains the boundary, a second attempt will most likely succeed, because the boundary will be different.
* I noticed that the content type for a file part is hardcoded as "application/octet-stream", with no way that I can see to override it. The problem is that it is hardcoded in FilePart, but (a) there isn't a way to add a Part explicitly, and (b) there's no way to tell MultipartPostMethod to use an alternative FilePart implementation. * There is no way to set additional characteristics of parts, such as the character encoding. This is a similar issue to the one above related to file parts, but applies to file and string parts. * The only way to create a file part is from a java.io.File instance. There is no way to use buffered data, or a stream, other than writing it to a File first. * There is no way to create multipart/mixed content. Don't get me wrong - I'm glad to see multipart content in HttpClient! I just wanted to share some review comments, perhaps to be addressed later. -- Martin Cooper > -----Original Message----- > From: Jeff Dever [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 01, 2002 12:26 PM > To: Jakarta Commons Users List > Subject: Re: [httpclient] > > > Ok, > > I added Matthew's MultiPartPost to commons-httpclient. I > adjusted the formatting > and made a few other minor changes, but it looks very good. > There are still a few > things that need to be done, which have been noted on the bug report: > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13165 > > Just a note about the stability of HttpClient. We have seen > MANY changes since > the 2.0 Alpha release last year. The MultiPartPost files > that Matthew submitted > in January applied with ZERO conflicts. This test shows > that the method > interface has been VERY stable. > > Way to go HttpClient! and thanks to Matthew for the code (and > Mark for bringing it > up again). > > > "Mark R. Diggory" wrote: > > > Please look at these old messages: > > > > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01701.html > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01702.html > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg01704.html > > Matthew Albright pretty much supplied everything to make this easily > included into the package back in January of this year. There was no > response to his messages. > > -Mark > > Jeff Dever wrote: > > >>I have a > >>MultipartPost method written for the Commons HttpClient that works with > >>files stored on the file system such that thier references can be handed > >>in and the method "streams" everything, much more effective. I've often > >>wondered why the MultipartPostMethod hasn't been added to the commons > >>httpclient. But that is also the beauty of the commons library as well, > >>you can write your own methods if need be. > >> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
