I get 505 HTTP error when invoking soap request from .NET client. This problem never apeared in 4.x Tomcat versions, I think it was introduced in 5.x versions of Tomcat. I'm using Axis 1.1 on the server side. The problem seems to apear when client makes second request with user credantials. On the server basic authorization is set. Below is a trace of soap a requests: ******************** First request from client ********************************* POST /axis/services/Version HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573) Content-Type: text/xml; charset=utf-8 SOAPAction: "" Content-Length: 545 Expect: 100-continue Connection: Keep-Alive Host: 127.0.0.1 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://localhost:8081/axis/services/Version" xmlns:types="http://localhost:8081/axis/services/Version/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:getVersion xmlns:q1="http://axis.apache.org" /></soap:Body></soap:Envelope> ********************* Response from server after first request **************************** HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="APS Webservices" Content-Type: text/html;charset=utf-8 Content-Length: 954 Date: Wed, 06 Oct 2004 17:27:08 GMT Server: Apache-Coyote/1.1 <html><head><title>Apache Tomcat/5.0.28 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication ().</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/5.0.28</h3></body></html> ****************** Second request from client with Authorization set ******************** POST /axis/services/Version HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573) Content-Type: text/xml; charset=utf-8 SOAPAction: "" Authorization: Basic YXBzOnRlc3Q= Content-Length: 545 Expect: 100-continue Host: localhost:8081 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://localhost:8081/axis/services/Version" xmlns:types="http://localhost:8081/axis/services/Version/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:getVersion xmlns:q1="http://axis.apache.org" /></soap:Body></soap:Envelope> ******************* Response from server after second request ****************************** HTTP/1.1 505 HTTP Version Not Supported Date: Wed, 06 Oct 2004 17:27:08 GMT Server: Apache-Coyote/1.1 Connection: close
- Capture the exact request bytes - Open a telnet 127.0.0.1 8080 (with the default config) - Send the bytes If it still breaks, attach the said bytes to the bug report as a file, so that I can reproduce it. My understanding of the issue is that this your client is broken: it requires an expectation, which is not fulfilled (401), but sends the request body anyway (lol). Tomcat will use your request body as the first line of the next request, and then of course send a 505. Solution if my theory is correct: add the user-agent as a restricted user agent so that keep alive isn't used (or disable keep alive).
I found out that the problem is with first request from .NET soap client. After this first request following ones are okay because they don't contain first part which doesn't have user credantials. I never had this problem with same client but with Tomcats 4.x. First shot contains actually two requests this is the trace of those requests: POST /axis/services/Version HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573) Content-Type: text/xml; charset=utf-8 SOAPAction: "" Content-Length: 545 Expect: 100-continue Connection: Keep-Alive Host: 127.0.0.1 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://127.0.0.1:8081/axis/services/Version" xmlns:types="http://127.0.0.1:8081/axis/services/Version/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:getVersion xmlns:q1="http://axis.apache.org" /></soap:Body></soap:Envelope>POST /axis/services/Version HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573) Content-Type: text/xml; charset=utf-8 SOAPAction: "" Authorization: Basic YXBzOnRlc3Q= Content-Length: 545 Expect: 100-continue Host: 127.0.0.1:8081 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://127.0.0.1:8081/axis/services/Version" xmlns:types="http://127.0.0.1:8081/axis/services/Version/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:getVersion xmlns:q1="http://axis.apache.org" /></soap:Body></soap:Envelope> *** Below is trace of response from server that I get using telnet ********* HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="APS Webservices" Content-Type: text/html;charset=utf-8 Content-Length: 954 Date: Thu, 07 Oct 2004 09:07:08 GMT Server: Apache-Coyote/1.1 <html><head><title>Apache Tomcat/5.0.28 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication ().</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/5.0.28</h3></body></html>HTTP/1.1 505 HTTP Version Not Supported Date: Thu, 07 Oct 2004 09:07:08 GMT Server: Apache-Coyote/1.1 Connection: close
I'm no expert at HTTP, but shouldn't Tomcat drop the TCP-connection after having sent the initial "401 Unauthorized"-resonse? This would cause .NET to do its re-post (with included authorization data in the HTTP Header) in a new TCP connection. In other words Tomcat should not use keep alive after a 401 Unauthorized. I think this is how IIS (and Tomcat 4.x i suspect) behaves.
Changing to a connector component.
This is invalid, please do not reopen.
Sorry for reopening. Shouldn't Tomcat somehow ignore the body of the first message? Doesn't the .NET Framework handle this correctly when it: 1. Posts soap message 2. Receives 401 Unauthorized 3. Reposts and this time includes authorization data (since it was requested)
This report is invalid, please do not reopen it. The M$ client obviously misuses expectations. The solution is to either set this user-agent as restricted so that it uses HTTP/1.0, or to disable keep-alive.
Can you please be more specific? What is wrong with the requests from the client? I can't tell if you have issue with data on the original or second request. The client does not know that it will be challenged until it sends the original request and receives the 401. Furthermore, the HTTP spec RFC 2616 Section 10.4.2 states: - "The client MAY repeat the request with a suitable Authorization header field." It does not indicate that the request should not contain data. If you could point us to the specification that these requests violate that would help a lot.
One additional comment it almost seems that Tomcat is not honoring the Content-Length header. If I read this correctly, you use the first line of the body original request as the first line of the second request. Shouldn't you discard the content specified by Content-Length.
(In reply to comment #8) > Can you please be more specific? What is wrong with the requests from the > client? I can't tell if you have issue with data on the original or second > request. The orignal request. See RFC 2616 Section 8.2.3. And, like Remy has said many times, this is invalid, so please stop wasting everybody's time by reopening it.
Sorry to waste your time. Many thanks, this is the answer I was looking for. It was not clear from the earlier responses.
(In reply to comment #10) > > Can you please be more specific? What is wrong with the requests from the > > client? I can't tell if you have issue with data on the original or second > > request. > The orignal request. See RFC 2616 Section 8.2.3. > And, like Remy has said many times, this is invalid, so please stop wasting > everybody's time by reopening it. Hello folks, I'm having a problem similar to the piotr's one, but in a different context and concluded that the .net client does not have a bad behavior. Tomcat on the other side isn't behaving improperly, but could behave better. Here goes: On section 8.2.3 it states that a client does not need to wait indefinitively for a server to respond with an 100 Continue message before starting to send it's body content of a request with the expect header. The M$ does it, and I believe they do it for performance reasons (perhaps it's a: "we ask if we can, but let's starting sending while the response does not come back, we win time if the response is positive") while the spec says that it's ok to do that because of the compatibility with older implementations of HTTP. It also says that if the server starts to receive data from the client, he may ommit the 100 continue response message. Plus, it also says that, when the server refuses an request with the expect header, and already received data it MAY close the transport connection or it MAY to continue read and then discard the rest of the request. So, TOMCAT doesn't do either, but does half of the second MAY. Now, if 505 error occurs because of the data on input stream (the body of the previous request) that is understood as a new request, I believe that the SPEC is not very clear about the issue and perhaps it should be more 'rule- enforcing'. In that case I believe that the server SHOULD close the transport connection OR it SHOULD read all data AND then discard it. Since TOMCAT already reads it (i supose it is the origin of the 505 error), I believe it also should discard it. That would be great for me, since I wouldn't need to add a if-command in my code :) Best regards, Miguel Figueiredo
It is obviously implied that the client MUST (caps as per the spec) wait a reasonable amount of time (Tomcat will return the 401 response nearly instantaneaously). If it does not, then there's absolutely no point in using expectations, and they should just remove the header. The spec is great and all, but there's little possibility to determine, if a client announces an expectation but doesn't use it (which isn't explicitely forbidden), if more data is subsequent pipelined requests, or if it's the body which was incorrectly sent. I believe Tomcat's behavior is the intended one. If you want the other behavior, you have one line of code to remove (inputBuffer.setSwallowInput(false); in Http11Processor), or add 401 as a disconnect status code. Tomcat reads the rest of the stream as the next request, so the last part of your comment isn't accurate.