Is there a RFC that describes best behaviour of server and client in
this situation?
On my opinion Tomcat behaves correctly. If client doesn't send proper
credentials it is dangerous and useless to read all input data.
I've switched off the connection keep alive at Connector config. And now
client doesn't suffer by closing a socket. So this is a solution for
"bad" .net client.
Jan.
When client sends a request there are written 2 lines at tomcat access log:
192.168.1.211 - - [03/Jun/2013:16:02:24 +0200] "POST
/ades-server/adesOperationsWebService HTTP/1.1" 401 951
192.168.1.211 - - [01/Jan/1970:00:59:59 +0100] "<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/";><s:Body null" 400 -
Basically the .net client never sends Authorization header at first time.
I used wireshark to see the communication:
1. C sends packet with http headers.
2. C sends packet with first part of soap xml request that begins <s:Envelope
...
3. S replies 401 Unauthorized.
4. S replies 400 Bad Request.
5. S sends RST (reset packet).
I can't offer an answer, but sympathy and a workaround:
We ran into this exact same issue when we moved to Apache httpd webservers. We opted to
disable keepalive for "MS Web Services" clients with:
BrowserMatch "MS Web Services" nokeepalive
rather than fighting an RFC interpretation battle...
It looks like similar could be done in tomcat with "restrictedUserAgents"
option on the http connector: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
-- Bill
---------------------------------------------------------------------
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]
