hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTPCLIENT-1350
Date Tue, 07 May 2013 13:48:25 GMT
On Tue, 2013-05-07 at 08:54 -0400, Karl Wright wrote:
> bq. The problem is that older (and broken HTTP/1.1) will have no chance to
> respond at all if the client waits forever for a 100 status.
> 
> I understand this concern, but remember that the user had to explicitly
> enable USE_EXPECT_CONTINUE in the first place.  If they were dealing with
> broken servers that did not properly support expect/continue, then why
> would they do that?  In other words, we already have a good window into the
> user's intent here - no need to code for least common denominator.
> 
> Karl
> 

I remember that but still of opinion we should comply with the
requirements of the HTTP spec. Not every application can expect a
particular protocol compliance level from all potential target and proxy
servers. One might want to enable the 'expect: continue' handshake by
default and still expect the client to handle an occasional
non-compliant behavior.

Oleg       

> 
> 
> On Tue, May 7, 2013 at 8:48 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> 
> > On Tue, 2013-05-07 at 08:38 -0400, Karl Wright wrote:
> > > If you are willing to wait forever on a socket, then waiting forever for
> > > the server to respond seems perfectly reasonable as well.
> > >
> > > It is clear from the w3c spec you quoted that expect/continue's primary
> > > mode is to *not* just continue.  It allows that for compatibility with
> > > older implementations only.
> > >
> >
> > The problem is that older (and broken HTTP/1.1) will have no chance to
> > respond at all if the client waits forever for a 100 status. We should
> > follow the spec recommendation in this instance and have a finite
> > waiting time for a 100 status in my opinion.
> >
> > Oleg
> >
> > > Karl
> > >
> > >
> > >
> > > On Tue, May 7, 2013 at 8:35 AM, Oleg Kalnichevski <olegk@apache.org>
> > wrote:
> > >
> > > > On Tue, 2013-05-07 at 08:30 -0400, Karl Wright wrote:
> > > > > By default, I'd make it the same as the socket timeout.  Makes
> > sense, no?
> > > > >
> > > >
> > > > Socket timeout is indefinite (zero) by default. We could pick the
> > > > greater value of socket timeout and, say, 5 seconds.
> > > >
> > > > Oleg
> > > >
> > > > > Karl
> > > > >
> > > > >
> > > > > On Tue, May 7, 2013 at 8:26 AM, Oleg Kalnichevski <olegk@apache.org>
> > > > wrote:
> > > > >
> > > > > > On Tue, 2013-05-07 at 08:03 -0400, Karl Wright wrote:
> > > > > > > Thanks - this allowed us to fix our problem, I believe...
> > > > > > > Only comment I have is that 2-3 seconds is perhaps too
short as a
> > > > > > default.
> > > > > > > If someone enabled expect-continue, presumably they have
a
> > reason to
> > > > use
> > > > > > > it, and such a short delay is inconsistent with that.
> > > > > > >
> > > > > > > Karl
> > > > > >
> > > > > > It is really hard to tell what default value would be more
> > appropriate.
> > > > > > 5 seconds?
> > > > > >
> > > > > > Oleg
> > > > > >
> > > > > > >
> > > > > > > On Tue, May 7, 2013 at 7:25 AM, Oleg Kalnichevski <
> > olegk@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, 2013-05-07 at 06:57 -0400, Karl Wright wrote:
> > > > > > > > > Hi Oleg,
> > > > > > > > >
> > > > > > > > > I know you were working on state cleanup for
the 4.2.5
> > release.
> > > >  I
> > > > > > think
> > > > > > > > > HTTPCLIENT-1350 may be related to this.  Would
you be
> > willing to
> > > > > > have a
> > > > > > > > > quick look, and recommend debug logging options
so that we
> > can
> > > > get
> > > > > > what
> > > > > > > > you
> > > > > > > > > think is needed to figure out the issue?
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > Karl
> > > > > > > >
> > > > > > > > Karl
> > > > > > > > I do not think this is a bug. Please see my comment
in the
> > JIRA.
> > > > > > > >
> > > > > > > > Oleg
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >



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


Mime
View raw message