You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/03/12 21:02:19 UTC
[HttpComponents][HttpCore] EntityGenerator and EntityWriter
interfaces revisited
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
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and
EntityWriter interfaces revisited
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2006-03-15 at 00:20 +0100, Ortwin Glück wrote:
>
> ...
> > 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
>
> IMHO this design inhibits reuse a bit. What if I would like to use the
> entity serializer outside the context of a message?
>
Odi,
At the very least the entity serializer needs to know the protocol
version, which is usually communicated in the message header.
>
> > * 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
>
> Are these Clover figures?
>
These are Clover figures. The Clover coverage reports for HttpCore are
now always available at the HttpComponents web site
> > 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
>
> Wow - big effort, Oleg! You were not at work today? :-)
>
You know what? I work at home these days and I am free to hack on
HttpComponents any time I please ;-)
Cheers,
Oleg
> > Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter interfaces
revisited
Posted by Roland Weber <ht...@dubioso.net>.
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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter interfaces
revisited
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> * 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?
> 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
IMHO this design inhibits reuse a bit. What if I would like to use the
entity serializer outside the context of a message?
> * It is no longer necessary to have client-side and server-side impls of
> the EntitySerializer interface
That is a big achievement! And it feels very right.
> * Overall, things got simpler and cleaner
Sounds good.
> * 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
Are these Clover figures?
> 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
Wow - big effort, Oleg! You were not at work today? :-)
> Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter interfaces
revisited
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> 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.
Yes, things are much more to my liking now :-)
Good work!
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter
interfaces revisited
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: [HttpComponents][HttpCore] EntityGenerator and
EntityWriter interfaces revisited
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-03-13 at 14:40 +0100, Roland Weber wrote:
> Hi Oleg,
>
> > 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 .
>
> Did I complain loudly? I thought that was just in my mind :-)
You did mention that as an API deficiency at some point of time while we
were discussing the possibility of moving the transfer encoding handling
code from the HTTP connection classes to the HTTP request / response
interceptors.
> Seriously, I had also spend some brief thoughts about that point,
> but I don't remember reading anything about it on the mailing list.
> I guess you have gathered feedback elsewhere.
>
> > (1) Rename EntityWriter to HttpEntitySerializer and EntityGenerator to
> > HttpEntityDeserializer (I am open to different (better) names).
>
> Fine by me. No better names jump into my mind.
>
> > (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
>
> The Transfer-Encoding header is the responsibility of the transport
> layer, I have no problem with having it set by the serializer. For the
> Content-Length header, I would prefer to see an exception thrown if an
> inappropriate header has been set explicitly. For both, actually.
>
Agreed.
I'll start hacking on it tomorrow
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents][HttpCore] EntityGenerator and EntityWriter interfaces
revisited
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> 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 .
Did I complain loudly? I thought that was just in my mind :-)
Seriously, I had also spend some brief thoughts about that point,
but I don't remember reading anything about it on the mailing list.
I guess you have gathered feedback elsewhere.
> (1) Rename EntityWriter to HttpEntitySerializer and EntityGenerator to
> HttpEntityDeserializer (I am open to different (better) names).
Fine by me. No better names jump into my mind.
> (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
The Transfer-Encoding header is the responsibility of the transport
layer, I have no problem with having it set by the serializer. For the
Content-Length header, I would prefer to see an exception thrown if an
inappropriate header has been set explicitly. For both, actually.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org