[PATCH] EntityEnclosingMethod 'modality' fix (take 2)

["Kalnichevski, Oleg" <ol...@bearingpoint.com>]

Mike,

Another shot at it. Let me know what you think

Oleg


-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu]
Sent: Monday, April 14, 2003 14:56
To: Commons HttpClient Project
Subject: Re: [PATCH] EntityEnclosingMethod 'modality' fix


> Oh, man. I totally forgot about it. What it means that the entire  
> PostMethod needs to be rewritten. I really hate having to do so. I  
> can't help thinking that this patch makes EntityEnclosingMethod &  
> PostMethod an awful mess for a very little gain. Having to juggle  
> around with a stream, a string and an array of NameValuePair I fear  
> makes PostMethod error-prone and may lead to undesirable results under  
> certain circumstances. I am leaning towards just documenting the  
> assumption regarding 'Content-Type' header and leaving most of the  
> EntityEnclosingMethod & PostMethod classes as they are. It all gets  
> just way too ugly.

I agree, it it getting a little ugly, but I think it's necessary.   
Another way of looking at this would be to listen on charset changes.   
When the request body is set via a string it would be encoded as  
before.  The difference would be that when the charset was changed the  
content would be decoded using the original charset and then re-encoded  
with the new charset.  I think this is a tradeoff of one hack for  
another, but it keeps from having to store a bunch of different  
different content sources.

> There's no use case for getRequestBody() & getRequestBodyAsString()  
> methods. Plain and simple. They have been created for API completeness  
> and symmetry with setRequestBody(InputStream) & getRequestBody(String)  
> methods. If implemented as buffering methods these methods should be  
> invoked by the end user only. There is really no good reason to use  
> these methods in the very first place, as the content, if the need be,  
> should be re-read from its source, rather from PostMethod.  
> Nevertheless, since these methods exist, they should be safe to use.  
> Consider the following situation:
> ----------------------------------------------------------------------- 
> --------
> PostMethod httppost = new PostMethod("/whatever");
> // Use unbuffered input stream
> InputStream instream = getMyInputStream();
> httppost.setRequestbody(instream);
> httppost.setRequestContentLength(PostMethod.CONTENT_LENGTH_CHUNKED);
> // Read the content and return it as a string.
> httppost.getRequestBodyAsString()
> // Since the content has not been buffered, the following method.
> // will return an emptry string
> httppost.getRequestBodyAsString()
> // Will post an empty request body
> client.executeMethod(httppost);
> ----------------------------------------------------------------------- 
> ---------

Yes, I assumed that was what you were trying to fix.

> Method bufferContent() is a private method that is called not only  
> from getRequestBody*() methods but a few others as well. I am missing  
> your point here. Can you shed a bit more light on it?

Well, my point was a little vague and not well though out:)  Mostly I  
was just noticing that these three methods are all testing similar  
conditionals.  That's about it.

Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org