Hi,

We have an IIS 6.0 server running Tomcat. Most of the time the application
works fine. However, occasionally IIS returns (Bad Request - Invalid Verb)
error. If we submit the same request again, the server returns the expected
data. This happens with regardless of what client we use. We have tried IE
and Firefox.

Environment:

IIS 6.0
Tomcat 5.5
isapi_redirect.dll is installed for communication between IIS and Tomcat


Any suggestion would be appreciated.

Thanks.

Re: IIS, Tomcat and Invalid Verb errors by Daniel

Daniel
Wed Jan 10 09:58:38 CST 2007

Mike wrote on Wed, 10 Jan 2007 10:11:03 -0500:

> Hi,
>
> We have an IIS 6.0 server running Tomcat. Most of the time the application
> works fine. However, occasionally IIS returns (Bad Request - Invalid Verb)
> error. If we submit the same request again, the server returns the
> expected data. This happens with regardless of what client we use. We have
> tried IE and Firefox.
>
> Environment:
>
> IIS 6.0
> Tomcat 5.5
> isapi_redirect.dll is installed for communication between IIS and Tomcat
>
> Any suggestion would be appreciated.

A quick Google on this error brings up loads of results, might be worth
looking through them. For instance, it's likely caused by there being no
HTTP/1.1 in the initial request, possibly being stripped out by something
between the clients and IIS.

Dan



Re: IIS, Tomcat and Invalid Verb errors by Mike

Mike
Wed Jan 10 15:58:10 CST 2007

Dan,

Thank you for your reply. I tried searching Google but none of the link
provided any useful results. The httperr1.log file contains an error line,
which looks like:

2007-01-10 20:58:44 208.242.14.199 4009 82.165.177.224 80 HTTP/0.0 Invalid -
400 - Verb -

I am not sure where did this HTTP/0.0 come from. I am sure the client is
sending appropriate request (containing HTTP/1.1). I checked the client
request headers through a proxy server.

Besides, the most annoying thing is that if I hit the refresh button on the
client browser the web server serves the correct results the next time.

Regards.






"Daniel Crichton" <msnews@worldofspack.com> wrote in message
news:uzQWyANNHHA.320@TK2MSFTNGP06.phx.gbl...
> Mike wrote on Wed, 10 Jan 2007 10:11:03 -0500:
>
>> Hi,
>>
>> We have an IIS 6.0 server running Tomcat. Most of the time the
>> application
>> works fine. However, occasionally IIS returns (Bad Request - Invalid
>> Verb)
>> error. If we submit the same request again, the server returns the
>> expected data. This happens with regardless of what client we use. We
>> have
>> tried IE and Firefox.
>>
>> Environment:
>>
>> IIS 6.0
>> Tomcat 5.5
>> isapi_redirect.dll is installed for communication between IIS and Tomcat
>>
>> Any suggestion would be appreciated.
>
> A quick Google on this error brings up loads of results, might be worth
> looking through them. For instance, it's likely caused by there being no
> HTTP/1.1 in the initial request, possibly being stripped out by something
> between the clients and IIS.
>
> Dan
>



Re: IIS, Tomcat and Invalid Verb errors by Daniel

Daniel
Thu Jan 11 03:49:51 CST 2007

Mike wrote on Wed, 10 Jan 2007 16:58:10 -0500:

> Dan,
>
> Thank you for your reply. I tried searching Google but none of the link
> provided any useful results. The httperr1.log file contains an error line,
> which looks like:
>
> 2007-01-10 20:58:44 208.242.14.199 4009 82.165.177.224 80 HTTP/0.0
> Invalid - 400 - Verb -
>
> I am not sure where did this HTTP/0.0 come from. I am sure the client is
> sending appropriate request (containing HTTP/1.1). I checked the client
> request headers through a proxy server.
>
> Besides, the most annoying thing is that if I hit the refresh button on
> the client browser the web server serves the correct results the next
> time.

At least a few of the posts I found suggested possible problems with network
cards, or intervening hardware, corrupting the data packets so that when
they get to IIS the HTTP headers are unreadable or missing parts. Refreshing
would then "fix" this because the packets are resent and not corrupted. To
find out where the problem is you'll have to install a packet sniffer and
record all packets, picking out those where the error appears and looking at
the actual request packets from the client.

Dan