You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hc.apache.org by bu...@apache.org on 2006/02/04 17:04:43 UTC

DO NOT REPLY [Bug 38509] New: - entities and connection handling incomplete

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38509>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38509

           Summary: entities and connection handling incomplete
           Product: HttpClient
           Version: 4.0
          Platform: Other
               URL: http://mail-archives.apache.org/mod_mbox/jakarta-
                    httpclient-
                    dev/200602.mbox/%3c43E38663.7040900@dubioso.net%3e
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HttpCommon
        AssignedTo: httpclient-dev@jakarta.apache.org
        ReportedBy: http-async@dubioso.net


1. entities can not be explicitly disconnected from the underlying stream
2. entities do not tell whether they have an underlying stream

patch follows

cheers,
  Roland

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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

Re: [Bug 38509] - entities and connection handling incomplete

Posted by Roland Weber <ht...@dubioso.net>.

Hi Oleg,

>>I would rather prefer an explicit IllegalStateException when
>>getContent() is called on an entity whose content has already been
>>consumed.

I've implemented that. An IllegalStateException is thrown when the
content of BasicHttpEntity is obtained several times, or if it is
obtained without being set at all. Now I have 12 failing test cases.
This will take a while to clean up.

cheers,
  Roland

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

Re: [Bug 38509] - entities and connection handling incomplete

Posted by Roland Weber <ht...@dubioso.net>.

Hi Oleg,

> I would rather prefer an explicit IllegalStateException when
> getContent() is called on an entity whose content has already been
> consumed.

Yes, that's better.

>>The second item is the return value of writeTo(). Oleg, did
>>you have a particular use case in mind when you defined that?
> 
> I am fine to revert the change 

Ok. I'll make this my test case for creating a patch that I can
apply with "diff". I can't promise a result for tomorrow though.
It's the Snooker final and they're broadcasting both sessions :-)

cheers,
  Roland

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

Re: [Bug 38509] - entities and connection handling incomplete

Posted by Oleg Kalnichevski <ol...@apache.org>.

On Sat, 2006-02-04 at 17:40 +0100, Roland Weber wrote:
> Hi Oleg, hi all,
> 
> I've noticed some peculiarities in the HttpEntity interface.
> 
> First of all, the JavaDocs for getContent() explicitly state
> that it is a programming error to return the same InputStream
> for multiple invocations. In http-async, I used
>     entity.getContent().close();
> to make sure that the response entity is read to the end before
> the connection is re-used. That was a programming error on my part.
> What's worse, it worked: BasicHttpEntity does return the same
> InputStream on each call, and so does GzipDecompressingEntity.
> 
> One way to solve this is to change the JavaDocs so that only
> repeatable entities are required to return a new InputStream
> on each invocation. Another way to solve this is to change the
> non-repeatable entities to return their one and only stream
> only for the first invocation, and null for the following ones.
>
> I prefer the second option. No matter what we do, somebody is
> going to use entities the wrong way. But if null is returned,
> they get an exception and can fix their code quickly. If some
> entities return the same stream and others a new one, then the
> problems will be very hard to debug.
> 

I would rather prefer an explicit IllegalStateException when
getContent() is called on an entity whose content has already been
consumed.

> 
> The second item is the return value of writeTo(). Oleg, did
> you have a particular use case in mind when you defined that?

Yes, I did. I introduced this condition, while working on a Tomcat
Coyote connector implementation based on HttpCore. Think of Servlet API,
which does not have a concept of an entity as such. In a servlet one
simply uses an OutputStream or a Writer to stream out the content after
the HTTP response header has been committed. Initially I used a
bastardized HttpEntity to keep a reference to the underlying
OutputStream instance. Later on I completely gave up on the idea of
using the HttpEntity interface in the context of a servlet engine and
simply implemented a Coyote specific HTTP connection class capable of
stream content directly.

I admit this idea was ill conceived. I am fine to revert the change 

> If 'false' is returned, then some other thread must be busy
> writing the entity asynchronously. But I'm not aware of means
> to synchronize with that thread's operation. For example, the
> default implementations of the client connection and entity
> writer will, after a call to conn.sendRequestEntity(), simply
> return while some thread somewhere is still writing to the
> connection.
> This feature feels like a big can of worms to me. If there is
> no specific use case, we should rather require writeTo() to
> write the entity completely in all cases.
> 
> 
> And finally, I had some problems to write JavaDocs for isChunked.
> The meaning of the flag is different for outgoing and incoming
> entities. I completely failed to come up with a recommendation
> for wrapping entities. Please review the JavaDocs I've written.
> 

Looks good to me.

Cheers,

Oleg


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