On 16/08/2010 09:52, Hans Wahn wrote: > I'd like to provide more information. Any suggestions what is the best > way to accomplish that? > > Hans > > > 2010/8/16 Pid <p...@pidster.com>: >> On 13/08/2010 23:24, André Warnier wrote: >>> Pid wrote: >>>> On 13/08/2010 11:52, Hans Wahn wrote: >>>>> 2010/08/12 20:20:17:796 CEST [DEBUG] wire - << "HTTP/1.1 100 >>>>> Continue[EOL]" >>>>> 2010/08/12 20:20:17:796 CEST [DEBUG] wire - << "[EOL]" >>>>> 2010/08/12 20:20:17:796 CEST [DEBUG] headers - << HTTP/1.1 100 Continue >>>>> 2010/08/12 20:20:17:796 CEST [DEBUG] wire - >> "testName=testValue" >>>> >>>> I suspect that the value pair is being sent as a body, but the server is >>>> expecting a header. What is the proper thing for a client to send after >>>> receiving the 100 Continue message? >>>> >>>> >>> as per RFC2616, 8.2.3 >>> >>> Requirements for HTTP/1.1 origin servers: >>> >>> - Upon receiving a request which includes an Expect request-header >>> field with the "100-continue" expectation, an origin server MUST >>> either respond with 100 (Continue) status and continue to read >>> from the input stream, or respond with a final status code. The >>> origin server MUST NOT wait for the request body before sending >>> the 100 (Continue) response. If it responds with a final status >>> code, it MAY close the transport connection or it MAY continue >>> to read and discard the rest of the request. It MUST NOT >>> perform the requested method if it returns a final status code. >>> >>> So it looks like the client is right in that case, to just send the body. >>> >>> But to me it loks as if the server send the 100 Continue status, and >>> then "went away", and that indeed when the client sends this body, it is >>> interpreted by the server as a new request, which should start with a >>> request line. >>> >>> This could be a server bug, or else it is the client which has created a >>> new connection and sends the body onto it. I am not quite sure at this >>> point if we are seeing everything in the trace log. >>> Anyway, something is badly out of sync. >> >> Agreed. More information required.
See above, regarding trace log. Also, providing a stack trace if there is one from the error log and any access log data. You might consider *not* sending the 100 header and just proceeding as normal. p >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
