RFC: HttpClient: PostMethod Change Proposal

["Paul C. Bryan" <em...@pbryan.net>]

Dear Developers:

I would like to solicit your comments and opinions on the following 
proposed change to PostMethod.


Description:

I would like to propose a change to the PostMethod class, to allow the 
request body to be optionally set directly from an InputStream. 
Presently, the only way a PostMethod's request body can be se is through 
parameters.


Rationale:

My application in particular is a servlet, which receives requests and 
acts as a quasi-proxy, to make requests on behalf of the user to 
services, providing transparent session management. Parsing parameters 
and resubmitting parameters tends to (usually subtly, but not always) 
change the request body. Being able to set the PostMethod body to the 
incoming request body verbatim makes for cleaner proxy behavior.


Details:

I propose a new method: public void setRequestBody(InputStream), which 
will read the input stream and populate the request body. Checks will be 
in place to ensure only body can be set xor parameters can be set. Most 
of the code would be adapted from PutMethod.setRequestBody(InputStream).


Alternative 1:

I can subclass the PostMethod class and provide this functionality, but 
in order to do so, I would propose that the requestBody variable be 
changed from private to protected.


Alternative 2:

I call this the "keep it out of HttpClient" option. I can write an 
entirely new Method subclass, that duplicates the functionality of 
PostMethod, except body is set with stream instead of parameters.


Your Opinion:

Please check the box that best represents your opinion of this proposal.

[ ] I agree with the proposal as outlined.
Make it so.

[ ] Alternative 1.
Change visibility of requestBody, and implement your own subclass of 
PostMethod.

[ ] Alternative 2.
Paul, go away. Implement your own Method subclass.

[ ] None of the above.
Shouldn't this list moderate this kind of riff-raff? How can I 
unsubscribe Paul from submitting messages to this mailing list?


Thank you in advance for your time and comments.


Yours truly,

Paul C. Bryan <em...@pbryan.net>
http://pbryan.net/


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