RE: [httpclient]

[Martin Cooper <ma...@tumbleweed.com>]

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:jsdever@sympatico.ca]
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [httpclient]

[Jeff Dever <js...@sympatico.ca>]

>
> >* 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.
> >
> >
> It would be nice to have these options as well. I found it easier to
> deal with building the request off of files because otherwise the memory
> requirements can get out of hand when dealing with larger files. Is it
> valid to assume that one can always create a temp file in JVM and use
> that to store the contents prior to the request? Or is it more
> benificial to allow one to instantiate off of other sources (Streams or
> buffers)? In such cases, would the content either stay in memory or get
> stored temporarily in a file somewhere behind the scenes (another
> possible option)?

The use of a stream is a common pattern in HttpClient, and also applies here.  If
they want to stream file, using a FileInputStream is pretty easy to create for
the client, and can be handled just like any other stream.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [httpclient]

["Mark R. Diggory" <md...@latte.harvard.edu>]

No complaints here. If you see avenues for improvement, I'm sure we're 
all for that! I'm not sure if we can drum up Matthew Albright who 
originally wrote the code. It would be cool to bounce stuff off of him 
because, as author, he may be able state the pros/cons of his decisions.

If not, we'll just have to get into the details ourselves.

Martin Cooper wrote:

>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.
>  
>
Sounds like a good idea.

>* 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.
>  
>
It would be nice to have these options as well. I found it easier to 
deal with building the request off of files because otherwise the memory 
requirements can get out of hand when dealing with larger files. Is it 
valid to assume that one can always create a temp file in JVM and use 
that to store the contents prior to the request? Or is it more 
benificial to allow one to instantiate off of other sources (Streams or 
buffers)? In such cases, would the content either stay in memory or get 
stored temporarily in a file somewhere behind the scenes (another 
possible option)?

It sounds like all could use review and improvement. If there are 
properties that would be good to make available via get/set methods. 
This should be releatively easy. I'm not sure if this will get us into 
deep water in having to deal with various "codecs" and encoding issues 
that can result. Anyways, it sounds like some of these steps should be 
well planned before embarking upon them.

>* 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:jsdever@sympatico.ca]
>>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:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>