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][HttpCore] EntityGenerator and EntityWriter interfaces revisited
Date Wed, 15 Mar 2006 08:15:06 GMT
Hi Odi,

>> * Default entity serializer impl changed to rely on message headers when
>> serializing an entity instead of the HttpEntity properties which may be
>> inconsistent with the Content-Length and Transfer-Encoding headers
>> contained in the message.
> This may be a naive question. But why can't we make them consistent?

The entity has a method isChunked, which depends exclusively on the
entity implementation. But if the entity is serialized for an HTTP/1.0
connection, it can not be chunked. Theoretically an inteceptor may
also add transfer encodings other than chunked, though we are not
likely to see any cases in real life.
With the modified structure, an interceptor can analyze what transfer
encoding and content length values the entity suggests, and then
override these suggestions based on additional information such as
the protocol version or parameter settings. If the user decides
"no chunked encoding" or "no Content-Length header", that should
take precedence.
Expecting all entity implementations to correctly support methods
like setChunked() and setContentLenght() would make the framework
much more fragile, and the interfaces harder to implement. And it
would not address the theoretical problem of non-chunked transfer

> IMHO this design inhibits reuse a bit. What if I would like to use the
> entity serializer outside the context of a message?

You'll have to pass in a dummy message with the HTTP version set
to 1.1 and the Transfer-Encoding header set to the encoding you want
to use for (de)serializing. The Content-Length header will only add
consistency checking, but does not affect the data representation.

We could add another method that expects only the Transfer-Encoding
header value instead of a message, and creates the dummy message
from that. But I suggest to defer that until we see actual demand.


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

View raw message