hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: [http-common] RFC: HttpEntity, HttpIncomingEntity, HttpOutgoingEntity revisited
Date Thu, 28 Apr 2005 06:20:48 GMT
Hi Oleg,

Mike's note made me think about this again...

> (2) HttpIncomingEntity interface can be gotten rid of. After all it is
> perfectly reasonable for any generic entity to be able produce its
> content. getInputStream method gets moved to HttpEntity

Do we need a public getInputStream() in the generic interfaces anyway?
My idea was that the InputStream is used internally by the (incoming)
entity to parse it's content, and that only a stream-type entity would
provide "raw" access to it. So I would expect a protected getInputStream()
in a base class, rather than a public one in the interface.

> (3) Rename HttpOutgoingEntity to HttpStreamableEntity. As far as I am
> concerned ability to stream itself is optional behavior for an entity
> (akin to HttpEntityEnclosingRequest) which should be treated as such

My motivation for distinguishing between incoming and outgoing entities
was to keep the parsing and generating separate, although that sure is
overkill for the many simple entity types.
By moving one of the functionalities into the base interface, it becomes
mandatory. And thinking of multipart MIME for which there are different
parser implementations, I'd rather have the generation than the parsing

> Presently HttpResponse and HttpEntityEnclosingRequest return a generic
> HttpEntity interface in order to be useable on both client and server
> side. From the design purism perspective this is probably quite okay. At
> the same time in practical terms this approach requires HttpEntity to be
> cast to either HttpIncomingEntity or HttpOutgoingEntity all the time to 
> of any use. All these castings get quite irritating quite fast.

My idea was to use a factory pattern for instantiating incoming entities:

StringEntity se = (StringEntity) 

whereas the outgoing entities have a generic writeTo(OutputStream). On the
client side, entity enclosing requests would allow setting an outgoing 
and responses provide incoming entities. On the server, it's the requests
that provide the incoming entity and the responses expect an outgoing 
to be set. The opposite operations could either be forbidden, or they 
be implemented conditionally for "two-way" entities.

So I'd keep the incoming and outgoing entities as distinct attributes
in the base class for HttpMessage, rather than casting a single attribute
to either side. Again, sorry for not having the time to look into the 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message