You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Michael Becke <be...@u.washington.edu> on 2004/09/02 14:23:35 UTC
Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.
Hi Roland,
Yes, that was definitely part of the discussion, and this seems to be a
pretty good solution for that. Now that I've slept on it , I think
this also came up when were originally discussing isStale() and how to
determine if a connection is still valid. Does buffering at this level
cause problems here? My gut reaction is that is that is could, but
probably won't under most conditions. My feeling is that there
shouldn't be anything buffered between requests. Does anyone have a
good real-world test case for this?
Mike
On Sep 2, 2004, at 2:46 AM, bugzilla@apache.org wrote:
> 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=21329>.
> 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=21329
>
> Add InputStream buffering.
>
>
>
>
>
> ------- Additional Comments From rolweber@de.ibm.com 2004-09-02 06:46
> -------
> Hi Mike,
>
> the discussion usually centered around buffering for the response body.
> Since folks could just get the input stream and create their own
> buffered
> stream on top, there didn't seem to be a need to create a buffered
> stream
> within Http Client. (That's what I recall, I didn't check the
> archives.)
>
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.
Posted by Michael Becke <be...@u.washington.edu>.
Oleg,
Yes, I believe you are correct. The potential is there for this to be
an issue, but given how we currently handle requests I don't think it
should even come up. I'm +1 for the patch.
Mike
Oleg Kalnichevski wrote:
> Mike,
>
> I have been also thinking about repercussions on the reliability of the
> stale connection check. I tend to conclude that with the existing
> architecture (no HTTP pipelining support + response 'garbage' check)
> there is virtually no chance of reading past the response body.
> HttpClient always makes sure that
>
> (1) a new request can be executed over the same connection only after
> the previous response has been consumed in its entirety
>
> (2) drops the connection whenever it detects illegal content past the
> declared response body
>
> Am I missing something?
>
> Oleg
>
>
> On Thu, 2004-09-02 at 14:23, Michael Becke wrote:
>
>>Hi Roland,
>>
>>Yes, that was definitely part of the discussion, and this seems to be a
>>pretty good solution for that. Now that I've slept on it , I think
>>this also came up when were originally discussing isStale() and how to
>>determine if a connection is still valid. Does buffering at this level
>>cause problems here? My gut reaction is that is that is could, but
>>probably won't under most conditions. My feeling is that there
>>shouldn't be anything buffered between requests. Does anyone have a
>>good real-world test case for this?
>>
>>Mike
>>
>>On Sep 2, 2004, at 2:46 AM, bugzilla@apache.org wrote:
>>
>>
>>>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=21329>.
>>>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=21329
>>>
>>>Add InputStream buffering.
>>>
>>>
>>>
>>>
>>>
>>>------- Additional Comments From rolweber@de.ibm.com 2004-09-02 06:46
>>>-------
>>>Hi Mike,
>>>
>>>the discussion usually centered around buffering for the response body.
>>>Since folks could just get the input stream and create their own
>>>buffered
>>>stream on top, there didn't seem to be a need to create a buffered
>>>stream
>>>within Http Client. (That's what I recall, I didn't check the
>>>archives.)
>>>
>>>cheers,
>>> Roland
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>commons-httpclient-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.
Posted by Eric Johnson <er...@tibco.com>.
I thought about this as well this morning, and couldn't figure out any
flaws with the patch.
-Eric.
Oleg Kalnichevski wrote:
>Mike,
>
>I have been also thinking about repercussions on the reliability of the
>stale connection check. I tend to conclude that with the existing
>architecture (no HTTP pipelining support + response 'garbage' check)
>there is virtually no chance of reading past the response body.
>HttpClient always makes sure that
>
>(1) a new request can be executed over the same connection only after
>the previous response has been consumed in its entirety
>
>(2) drops the connection whenever it detects illegal content past the
>declared response body
>
>Am I missing something?
>
>Oleg
>
>
>On Thu, 2004-09-02 at 14:23, Michael Becke wrote:
>
>
>>Hi Roland,
>>
>>Yes, that was definitely part of the discussion, and this seems to be a
>>pretty good solution for that. Now that I've slept on it , I think
>>this also came up when were originally discussing isStale() and how to
>>determine if a connection is still valid. Does buffering at this level
>>cause problems here? My gut reaction is that is that is could, but
>>probably won't under most conditions. My feeling is that there
>>shouldn't be anything buffered between requests. Does anyone have a
>>good real-world test case for this?
>>
>>Mike
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.
Posted by Oleg Kalnichevski <ol...@bearingpoint.com>.
Mike,
I have been also thinking about repercussions on the reliability of the
stale connection check. I tend to conclude that with the existing
architecture (no HTTP pipelining support + response 'garbage' check)
there is virtually no chance of reading past the response body.
HttpClient always makes sure that
(1) a new request can be executed over the same connection only after
the previous response has been consumed in its entirety
(2) drops the connection whenever it detects illegal content past the
declared response body
Am I missing something?
Oleg
On Thu, 2004-09-02 at 14:23, Michael Becke wrote:
> Hi Roland,
>
> Yes, that was definitely part of the discussion, and this seems to be a
> pretty good solution for that. Now that I've slept on it , I think
> this also came up when were originally discussing isStale() and how to
> determine if a connection is still valid. Does buffering at this level
> cause problems here? My gut reaction is that is that is could, but
> probably won't under most conditions. My feeling is that there
> shouldn't be anything buffered between requests. Does anyone have a
> good real-world test case for this?
>
> Mike
>
> On Sep 2, 2004, at 2:46 AM, bugzilla@apache.org wrote:
>
> > 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=21329>.
> > 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=21329
> >
> > Add InputStream buffering.
> >
> >
> >
> >
> >
> > ------- Additional Comments From rolweber@de.ibm.com 2004-09-02 06:46
> > -------
> > Hi Mike,
> >
> > the discussion usually centered around buffering for the response body.
> > Since folks could just get the input stream and create their own
> > buffered
> > stream on top, there didn't seem to be a need to create a buffered
> > stream
> > within Http Client. (That's what I recall, I didn't check the
> > archives.)
> >
> > cheers,
> > Roland
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-httpclient-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
--
Oleg Kalnichevski | Senior Consultant | BearingPoint | Switzerland
Phone +41 43 299 6449 | Mobile +41 79 653 2562 | Fax +41 43 299 6550
www.bearingpoint.com
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org