commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <jdev...@nortelnetworks.com>
Subject RE: [HttpClient] Retriving an unbuffered stream
Date Mon, 26 Aug 2002 13:26:03 GMT

I *really* like the idea of the self closing input stream.  Not sure if it
needs its own derived class: its pretty reasonable behaviour.  How much
low-level access should we give them before it would be better for users to
just use a raw socket?  The primary purpose of this is to prevent buffering
of large responses (and requests).  Providing the minimum level of access in
order to accomplish this requirement is most desireable from an
encapsulation perspective.

HttpClient has to handle some pretty varied user types, with different
needs.
1) User just wants a simple connection to a web server with as many details
hidden from them as possible.
2) User wants to functionally test a web application with as many details
exposed as possible for validation purposes.

If the user sets a timeout and then does not do a read in time, then thats
up to the user.  It might be some part of the test but they set the
parameters.  
		"with power comes responsibility"


-----Original Message-----
From: Ortwin Gl├╝ck [mailto:ortwin.glueck@nose.ch]
Sent: Monday, August 26, 2002 8:27 AM
To: Jakarta Commons Developers List
Subject: Re: [HttpClient] Retriving an unbuffered stream


I am trying to get a patch ready for this issue.

However I'd like to point out a subtle problem that comes up along the 
way: Who is responsible for closing the socket?

Because if we do not buffer the response, we can not close the socket 
until the response is fully read. Moreover the socket must only be 
closed if the connection is not keep-alive.

In my opinion the stream should handle the closing of the connection:
Create a AutoClosingInputStream extends FilterInputStream that is used 
to close the socket after the end of the stream is reached. It is only 
used if this behaviour is desired. Disadvantage is the small performance 
penalty. Better ideas?

More problems may arise if the user set a SO_TIMEOUT on the socket. What 
happens if the user does not read the response stream for the duration 
of the timeout? Will the socket close itself down and so break the 
connection?

Comments appreciated.

Odi


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message