hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter interfaces revisited
Date Tue, 14 Mar 2006 20:31:50 GMT
On Sun, 2006-03-12 at 21:02 +0100, Oleg Kalnichevski wrote:
> Roland et al,
> 
> One of the complaints about HttpCore API we have been unable to resolve
> so far is an asymmetry between the process of entity serialization
> (represented by the EntityWriter interface) and that of entity
> de-serialization (represented by the EntityGenerator interface) was .
> Presently, EntityWriter is not meant to make any modification to HTTP
> messages in order to ensure the exact details of the content transfer
> mechanism being utilized is correctly communicated to the opposite side
> of the protocol. The EntityWriter interface implicitly assumes all
> relevant HTTP headers are taken care of elsewhere. This approach, of
> course, implies that the failure to provide the required protocol
> interceptor or, worse, to keep in sync implementation of the
> EntityWriter and the corresponding protocol interceptor will break HTTP
> connection.
> 
> I would like to suggest the following changes:
> 
> (1) Rename EntityWriter to HttpEntitySerializer and EntityGenerator to
> HttpEntityDeserializer (I am open to different (better) names). 
> (2) The HttpEntitySerializer will be required to set (override if
> needed) the 'Transfer-Encoding' and 'Content-Length' headers to ensure
> the integrity of the underlying HTTP connection
> 
> Any objections to that?
> 
> Oleg 
> 

Folks,

I refactored the entity serialization / deserialization code in HttpCore
to fix the API deficiency described above. Things should be more to the
Roland's liking. I also like the new API much better.

Summary:

* The idea to muck around with the message headers inside the entity
serializer turned out to be a bad one. By the time the serializer is
called, the message headers have already been committed. The
Content-Length or Transfer-Encoding headers still must be generated by
protocol interceptors.

* 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 way, the content entity is always 
guaranteed to be correctly serialized. The message headers are expected
to be set up by the protocol interceptors. This comes at the cost of a
small performance hit, as the EntitySerializer now has to parse HTTP
headers contained in the message. I believe it is the price worth
paying. Faster but less bullet-proof implementations are easily possible

* It is no longer necessary to have client-side and server-side impls of
the EntitySerializer interface

* Overall, things got simpler and cleaner

* More test cases. The test coverage is already at 65%, which is not too
bad, and I plan to bring it to 80% in the coming days

Please review the changes.

As far as I am concerned this is the last item that I wanted fixed
before ALPHA-1. I intend to call a formal vote on the HttpCore ALPHA-1
release sometime next week, provided no release blockers are found

Oleg



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


Mime
View raw message