Return-Path: Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@www.apache.org Received: (qmail 31914 invoked from network); 26 Feb 2004 11:27:41 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 26 Feb 2004 11:27:41 -0000 Received: (qmail 48613 invoked by uid 500); 26 Feb 2004 11:27:13 -0000 Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@jakarta.apache.org Received: (qmail 48517 invoked by uid 500); 26 Feb 2004 11:27:13 -0000 Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Commons HttpClient Project" Reply-To: "Commons HttpClient Project" Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 48501 invoked from network); 26 Feb 2004 11:27:12 -0000 Received: from unknown (HELO nose.ch) (195.134.131.71) by daedalus.apache.org with SMTP; 26 Feb 2004 11:27:12 -0000 Received: (qmail 20831 invoked from network); 26 Feb 2004 11:27:26 -0000 Received: from calvin.nose.ch (HELO nose.ch) (192.168.1.7) by nose.ch with SMTP; 26 Feb 2004 11:27:26 -0000 Message-ID: <403DD81D.5010209@nose.ch> Date: Thu, 26 Feb 2004 12:27:25 +0100 From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= Organization: NOSE Applied Intelligence User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, en-us MIME-Version: 1.0 To: Commons HttpClient Project Subject: Re: [RFE] provide request entities in a more abstract way References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Roland Weber wrote: > Hello Odi, > > is this meant as an extension or as a replacement for > directly passing the InputStream? It is meant to replace the direct passing of the InputStream. We would need to remove that method. Deprecation is possible with an internal wrapper that just throws an exception on the second call. > In the second case, > I would add something like isRepeatable() to handle cases > where it is indeed not possible to read the data twice. My point was to force the user to make it repeatable. Yet, I am not sure if that is a good idea. You may be right that not all (especially streaming) data in the world may be available twice. > I'd prefer an explicit check to some exception being > thrown from getAsStream(), where every implementor > may decide for a different class and/or message. > Can you fill me in on the details of the POST request: > does the InputStream provide the full HTTP message > body (entity) for the request, or is it possible to send > multiple parameters, each of them being a file or string > or something else? In the second case, RequestEntity > is probably a misleading name for the interface. The InputStream provides the complete body (=entity) of a request (i.e. everything after the headers). So the name is correct. If you are thinking of Multipart-MIME, this can be accomplished by an intelligent input stream that switches its source on the part borders. And I really think it is right to do it like that. An entity enclosing method is only aware that there *is* an entity. If this entity is composed out of several parts this should be completely transparent for the method and be handled outside of it. --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org