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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
