https://issues.apache.org/bugzilla/show_bug.cgi?id=57324
--- Comment #3 from Vamsi Krishna <vkris...@novell.com> --- I am attaching traces from my wireshark analysis. It captures 3 request response cycles. Please proceed to my notes at the end after the trace. ************************************************** 1) POST /someresource/ HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.18444) Content-Type: text/xml; charset=utf-8 Authorization: Basic VALIDCREDENTIALS= Host: serveraddress Content-Length: 327 Expect: 100-continue HTTP/1.1 100 Continue <request body sent> HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=utf-8 Content-Length: 424 Date: Mon, 08 Dec 2014 08:47:08 GMT <first response successful> 2) POST /someotherresource/ HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.18444) Content-Type: text/xml; charset=utf-8 Host: serveraddress Content-Length: 331 Expect: 100-continue HTTP/1.1 100 Continue <request body sent> HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 WWW-Authenticate: Basic realm="blah" WWW-Authenticate: blah realm="blah" Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 951 Date: Mon, 08 Dec 2014 08:47:09 GMT <response with possible error message> 3) POST /someotherresource/ HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.18444) Content-Type: text/xml; charset=utf-8 Authorization: Basic VALIDCREDENTIALS= Host: 10.71.65.156 Content-Length: 331 Expect: 100-continue *************************************************** * In the above trace, my client made two webservice calls in a total of 3 reply-request cycles. The first request marked with 1) was straight forward and completed successfully with Expect100continue behavior. * The second webservice call was split into two cycles by .NET and its unnecessary optimization. Without the Application Developers clear intent to do so, .NET sent the second request without any credentials triggering a 401 response from server. However, according to RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 "401" response does give a chance for client to resubmit its request with proper credentials. * The third request number 3) in the trace is .NET trial at doing the same i.e resubmitting the second request with credentials. Because of the change done by Tomcat, the client does not get a chance and the socket is closed by Tomcat. The problem is severe because , in all of this, Application Developer does not get any control from .NET and Client code simply breaks with an exception because .NET did not check the health of socket before making request 3) in the above trace. Agreed there is a lot of problem here in .NET and we can reach out to Microsoft, but going and patching each and every client out there is going to be really costly. Also, it can be argued that with this new change, Tomcat is not giving opportunity to client to resubmit the 401 challenged response, so it may be a violation of RFC. Also, my traces are not consistent with the original issue reported so I need someone to investigate further. The original issue may be something happening only when there is an intermediate node involved. I may not be an expert in all of this, but feel there is something Tomcat can do about all of this. I have also reopened the bug only to demonstrate my point, but not to violate the process in the forum. If it is still not convincing, please go ahead and close the case. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
