Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of vavra@602.cz designates
 209.85.212.181 as permitted sender)
Message-ID: <51ACBE25.4010801@602.cz>
Date: Mon, 03 Jun 2013 18:02:45 +0200
From: =?ISO-8859-2?Q?Jan_V=E1vra?= <vavra@602.cz>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: .net web service client calling Tomcat 7
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Hello,
  I have a METRO web service at Tomcat 7.0.39 (S). The service is under 
http basic authentication.
I have written own realm for http basic authentication. The realm's 
implementation is very small. It's something like read ini file with 
username with passwords. Few lines ...
Our customer wrote a .net 4.5 web service client - WCF (C).

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).

The http headers are:

POST http://xxx.xxx.cz:8080/ades-server/adesOperationsWebService HTTP/1.1
Content-Type: text/xml; charset=utf-8
VsDebuggerCausalityData: 
uIDPo/1qFcW8E5lEl/4q6vnckqsAAAAAsk/yOV26Z0GeRPNudW6KS8R+D9VgeudJgruTaBNYol8ACQAA
SOAPAction: ""
Host: xxx.xxx.cz:8080
Content-Length: 444815
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

I checked the Content-Length value against really sent data and these 
numbers match.
My questions are. Why tomcat doesn't continue reading data until the 
whole request is read? Is it some configurable option? Is it against a 
DOS attack?

I think that the reasons why tomcat considers  (2) as a new http request 
are:
   - not reading the full request data according the value Content-Length
   - Connection: Keep-Alive

I also tried curl client with intentionally not specifying Authorization 
header. Curl client doesn't send packet with data (2), but curl also 
complaints with message:
* HTTP error before end of send, stop sending

Thanks for any advice.
Jan.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org