Bug 31567 - 505 request error from .NET client
505 request error from .NET client
Status: RESOLVED INVALID
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP
5.0.28
PC Windows XP
: P3 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-10-06 17:33 UTC by Piotr Walczyszyn
Modified: 2005-02-03 08:14 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Walczyszyn 2004-10-06 17:33:42 UTC
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
Comment 1 Remy Maucherat 2004-10-06 18:00:51 UTC
- 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).
Comment 2 Piotr Walczyszyn 2004-10-07 10:18:24 UTC
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
Comment 3 Per Th 2004-11-19 16:52:11 UTC
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. 
Comment 4 Yoav Shapira 2004-11-19 16:58:42 UTC
Changing to a connector component.
Comment 5 Remy Maucherat 2004-11-19 18:11:23 UTC
This is invalid, please do not reopen.
Comment 6 Per Th 2004-11-22 10:09:15 UTC
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)

Comment 7 Remy Maucherat 2004-11-22 12:25:40 UTC
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.
Comment 8 Wade Poziombka 2004-12-22 22:29:45 UTC
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.
Comment 9 Wade Poziombka 2004-12-22 22:35:48 UTC
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.
Comment 10 william.barker 2004-12-22 23:12:32 UTC
(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.
Comment 11 Wade Poziombka 2004-12-22 23:38:10 UTC
Sorry to waste your time.  Many thanks, this is the answer I was looking for. 
It was not clear from the earlier responses.
Comment 12 Miguel Figueiredo 2005-02-03 17:02:24 UTC
(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
Comment 13 Remy Maucherat 2005-02-03 17:14:43 UTC
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.