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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
