hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Disabling retries
Date Mon, 11 Mar 2013 18:06:03 GMT
On Mon, Mar 11, 2013 at 01:59:03PM -0400, Karl Wright wrote:
> So, in your opinion, the following is a valid HTTP response?  And,
> sorry, it's not Resin, it's Apache Web Server:
> 
> >>>>>>
> HTTP/1.1 100 Continue
> HTTP/1.1 401 Unauthorized
> Date: Mon, 11 Mar 2013 17:16:49 GMT
> Server: Apache/2.2.22 (Unix)
> WWW-Authenticate: Basic realm="resin"
> Content-Length: 159
> Content-Type: text/html; charset=utf-8
> X-UA-Compatible: IE=EmulateIE7
> <<<<<<
> 
> FWIW, it also appears that this problem is acknowledged by the Apache
> webserver team as being real, since at least 2007:
> 
> http://www.gossamer-threads.com/lists/apache/users/340406
> 
> Karl
> 

Assuming these messages are sent in response to an entity enclosing request containing 'Expect:
100-continue' header, yes, they are. The first response is utterly useless and misleading
but correct from the protocol standpoint.

Oleg


> On Mon, Mar 11, 2013 at 1:48 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Mon, Mar 11, 2013 at 01:44:06PM -0400, Karl Wright wrote:
> >> To finish up this thread, it seems that Resin is the problem.  It
> >> sends TWO status lines - a "100 Continue" AND a "401 Unauthorized" in
> >> the same response in this situation.  An obvious garden-variety bug,
> >> which we'll report to the Resin people ASAP.
> >>
> >> Karl
> >>
> >
> > Karl
> >
> > From the HTTP protocol standpoint this behavior is perfectly legal. Basically Resin
chooses to not validate incoming entity enclosing requests early. This is not nice but not
a bug.
> >
> > Oleg
> >
> >
> >> On Mon, Mar 11, 2013 at 11:26 AM, Karl Wright <daddywri@gmail.com> wrote:
> >> > Turns out that HttpClient is doing just fine, submitting the right
> >> > headers etc.  It's the server in this case that is saying "100
> >> > Continue" instead of "401 Unauthorized".  And then when data is
> >> > actually transmitted it responds with 401.  Brilliant.
> >> >
> >> > The server is running on Resin, so it is possible there's a
> >> > configuration problem, or improperly coded webapp.  But in any case
> >> > the fix looks correct.
> >> >
> >> > Thanks again!
> >> > Karl
> >> >
> >> > On Mon, Mar 11, 2013 at 10:07 AM, Karl Wright <daddywri@gmail.com>
wrote:
> >> >> We tried enabling expect-continue but we're still getting the same
> >> >> behavior.  This is a bit of a surprise given the discussion so far.
 I
> >> >> will try to get a full debugging dump to see what is going on.
> >> >>
> >> >> Karl
> >> >>
> >> >> On Fri, Mar 8, 2013 at 12:18 PM, Oleg Kalnichevski <olegk@apache.org>
wrote:
> >> >>> On Fri, 2013-03-08 at 11:50 -0500, Karl Wright wrote:
> >> >>>> Trying again on a reply - google seems to have deleted my previous
attempt.
> >> >>>>
> >> >>>> > This is what the 'expect-continue' handshake is for. It
enables the
> >> >>>> > client to verify server expectations prior to sending
the request body.
> >> >>>>
> >> >>>> Is there a reason this isn't getting used? Is it gated by server
> >> >>>> behavior, or is there a setting in HttpClient that allows it
to work?
> >> >>>>
> >> >>>
> >> >>> It is turned off by default due to compatibility issues with older
> >> >>> (HTTP/1.0) proxies.
> >> >>>
> >> >>>> > HttpClient comes with a number of HttpEntity implementations
including
> >> >>>> > those backed by a byte array, a string or a file. Probably
all you have
> >> >>>> > to do is to use the right implementation.
> >> >>>>
> >> >>>> Problem is that ManifoldCF output connectors get an inputstream
handed
> >> >>>> to them, not a file.  But I was asking this question to see
if anyone
> >> >>>> knew why a resettable input stream wouldn't work.  Because,
it doesn't
> >> >>>> seem to.
> >> >>>>
> >> >>>
> >> >>> I am not sure I understand how resettable input stream could help
here.
> >> >>> One would effectively need to buffer the entire content of the
entity in
> >> >>> memory in order to be able to reset from the very end of the stream
to
> >> >>> the very beginning.
> >> >>>
> >> >>> 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