hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: HttpComponents: entities and connections
Date Sat, 28 Jan 2006 06:09:29 GMT
Hi Oleg,

> 'Chunk-encoding' and 'identity' are the only transfer codings in use
> nowadays and this is unlikely to change in our life time. I have never
> seen transfer compression used anywhere, because content compression is
> enough. 

Hm. I was implicitly assuming that all this compression stuff one reads
about when searching for "web acceleration" is primarily transfer-encoding.
But this mail, and the discussion leading up to it, suggests you are right
and I am wrong:

> Another point, the chunk encoding MUST be the last one applied, it

If we introduce an interface for pluggable transport encodings, it
shouldn't be restricted to just chunked plus one other. (Although
that would probably cover every reasonable use case I could come up
with.) On the sending side, putting request interceptors into the
right order will be sufficient. On the receiving side, the order of
the transport encodings is determined by the server via the header.
We know "chunked" is the last, any others can come in arbitrary
order. An interface for shuffling the response interceptors would
be far worse than my suggestion. But after reading above-linked
discussion, I no longer think we need pluggable transport encodings.

Everything else I mentioned as potential applications for stream
layering were add-ons: things you could do with the mechanism if
it's there, not things for which the mechanism is actually needed.

> I am not sure I understand entirely the problem you are having with
> http-async. You want to preprocess an entity before the connection is
> allocated? What for?  

Remember my mail about preprocessing being done by the application
thread, while the sending is done by the background thread? The
preprocessing is done before the request ever gets queued. That's
in the good old tradition of detecting problems as early as possible:
requests that fail in preprocessing are not worthy to be queued.
The connection will be allocated at the other side of the queue.
Have a look at SimpleHttpDispatcher.sendRequest if you find the time.

> The whole thing is that the order IS fixed. One cannot put the chunk
> codec in an arbitrary place. It MUST be the last coding applied.

See above. The order is fixed if there are no more than two encodings,
of which the last is necessarily "chunked".

> The only *real* problem that I see at the moment is that
> HttpEntityGenerator and HttpEntityWriter interfaces are not symmetric
> from the design purism standpoint.

I agree now. You mentioned an idea to refactor at the expense of
exposing the streams at the connection. If that refactoring requires
the connection to be available for preprocessing, I'd rather keep what
we have right now.

I had one other problem: I didn't know how to detect whether the
entity in the response is a "streaming" entity depending on the
underlying stream of the connection, or whether it is an entity
that has been read into memory completely. In the second case, the
connection can be re-used immediately, in the first case it can
only be re-used after the entity has been consumed or some kind
of abort has been triggered.
I've seen that the EntityGenerator interface returns a BasicHttpEntity,
so the entities generated by the DefaultHttpClientConnection are never
in memory. Still, the HttpClientConnection interface can be implemented
differently. But this can be addressed in the JavaDocs.

> More strongly I think we should put our efforts elsewhere at this point
> of time: HttpAsync, HttpNIO, HttpCookie and HttpAuth.

Fair deal. I might add HttpConn, since more sophisticated dispatchers
will require a connection pool.

> We can redesign
> HttpEntityGenerator and HttpEntityWriter at any moment before the API
> freeze (which is nowhere in sight)

That comes as a surprise to me. I thought the release of the http-core
alpha1 you are planning for March implies some kind of API freeze.
(Note to self: learn more about the HttpComponents release process :-)


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

View raw message