You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Ortwin Glück <or...@nose.ch> on 2004/02/26 10:46:34 UTC
[RFE] provide request entities in a more abstract way
Providing only an InputStream as a request body is not enough. We can
not automatically repeat such a request since we are unable to reset the
input stream without buffering it. I suggest we introduce an abstraction
for the source of request entities such as:
interface RequestEntity {
/**
* Provides an input stream of the request entity. The method may be
called
* more than once and must provide a virgin stream upon each call.
*/
InputStream getAsStream();
}
We can then provide convenience classes that implement this interface,
such as:
* class StringRequestEntity implements RequestEntity
* class FileRequestEntity implements RequestEntity
etc.
What does everybody think about this?
Odi
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer [email] ortwin.glueck@nose.ch
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [RFE] provide request entities in a more abstract way
Posted by Ortwin Glück <or...@nose.ch>.
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
Re: [RFE] provide request entities in a more abstract way
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Odi,
is this meant as an extension or as a replacement for
directly passing the InputStream? In the second case,
I would add something like isRepeatable() to handle cases
where it is indeed not possible to read the data 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.
cheers,
Roland
Ortwin Glück <or...@nose.ch>
26.02.2004 10:46
Please respond to "Commons HttpClient Project"
To: Commons HttpClient Project
<co...@jakarta.apache.org>
cc:
Subject: [RFE] provide request entities in a more abstract
way
Providing only an InputStream as a request body is not enough. We can
not automatically repeat such a request since we are unable to reset the
input stream without buffering it. I suggest we introduce an abstraction
for the source of request entities such as:
interface RequestEntity {
/**
* Provides an input stream of the request entity. The method may be
called
* more than once and must provide a virgin stream upon each call.
*/
InputStream getAsStream();
}
We can then provide convenience classes that implement this interface,
such as:
* class StringRequestEntity implements RequestEntity
* class FileRequestEntity implements RequestEntity
etc.
What does everybody think about this?
Odi
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer [email] ortwin.glueck@nose.ch
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org