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 encodings. > 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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
