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 <[email protected]> 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 <[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] > > > > --------------------------------------------------------------------- > 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]
