Handling multipart/x-mixed-replace content

[Joonas Koivunen <jo...@gmail.com>]

Hi there everyone!

I've just pieced together a simple implementation for $topic in a
somewhat "httpcomponent" fashion, splitting one HttpEntity into a
stream of actual HttpEntities.

I needed it to handle MJPEG stream from an IP camera. I'd like to
contribute this; while it's not perfectly good usage of HTTP it is
still deployed in the world.

The impl is rather ugly in it's current state, as I need to get the
SessionInputBuffer from IdentityInputStream and to get that, I need to
unwrap the entity as well. Also, it currently requires at least the
Content-Length header for each part, which shouldn't be a requirement,
we should be able to read until the next boundary.

To really contribute this I'd like to know why is there no easier way
to access SessionInputBuffer? It's really necessary if you don't want
to rewrite the whole class (reading bytes AND reading lines);
currently the only way to access it is through reflection, which is
not a real solution. Has there been any talk about adding framework
level access to SessionInputBuffer or have I missed something?

Simple usage example: http://paste.ubuntu.com/697938/ -- it'd be
clearner if it were injectable through ResponseInterceptor. Too bad
any entity set by an interceptor is wrapped, making it necessary to
employ reflection again.

-- 
-- Joonas Koivunen

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Handling multipart/x-mixed-replace content

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2011-09-27 at 18:43 +0300, Joonas Koivunen wrote:
> Hi there everyone!
> 
> I've just pieced together a simple implementation for $topic in a
> somewhat "httpcomponent" fashion, splitting one HttpEntity into a
> stream of actual HttpEntities.
> 
> I needed it to handle MJPEG stream from an IP camera. I'd like to
> contribute this; while it's not perfectly good usage of HTTP it is
> still deployed in the world.
> 
> The impl is rather ugly in it's current state, as I need to get the
> SessionInputBuffer from IdentityInputStream and to get that, I need to
> unwrap the entity as well. Also, it currently requires at least the
> Content-Length header for each part, which shouldn't be a requirement,
> we should be able to read until the next boundary.
> 
> To really contribute this I'd like to know why is there no easier way
> to access SessionInputBuffer? It's really necessary if you don't want
> to rewrite the whole class (reading bytes AND reading lines);
> currently the only way to access it is through reflection, which is
> not a real solution. Has there been any talk about adding framework
> level access to SessionInputBuffer or have I missed something?
> 
> Simple usage example: http://paste.ubuntu.com/697938/ -- it'd be
> clearner if it were injectable through ResponseInterceptor. Too bad
> any entity set by an interceptor is wrapped, making it necessary to
> employ reflection again.
> 

Hi Joonas

The main purpose of HTTP entities is to ensure that the underlying
connection aways remains in a consistent and potentially re-usable state
after a message has been transmitted over it. This is the same reason
why the session i/o buffers are not exposed through the public API: once
the user is able to read from and to write to the underlying connection
at will it is very difficult to ensure its state is consistent.

I have always been saying is that HttpClient API may not be suitable for
all kinds of use scenarios especially when the HTTP protocol needs to be
'bent' in some creative ways. You may be better off building your own
HTTP agent using HTTP transport and protocol components from HttpCore
and HttpClient modules. 

Hope this helps

Oleg 




---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org