IIS 6.0 gives some clients HTTP 400 Bad Request but not others?
Kyle
I have a Windows Server 2003 box with IIS 6.0 hosting a website for
SSRS (sql 2005 reporting services).
From the local intranet most clients can use a hyperlink http://servername/reports
and get to the reports server just fine, web server responds, gives
them what they need, all is good.
Unfortunately, I have a small but growing number that are receiving a
strange error on IE7 and IE8.
HTTP 400 Bad Request: Invalid Verb
If I understand right this error implies that the client machine was
able to contact the server (the website is alive) but for whatever
reason there is a bad (insert unknown component here) causing a
disconnect?
Anyone have any ideas how I may go about figuring out which component
is causing this Bad Request Error?
For my clients: The servername is setup as a 'Local Intranet' site.
Most clients (55 of 60) can click on a link to http://servername/reports
and it's good to go, it uses integrated windows authentication.
The other 5 out of 60 get bad request invalid verb from http://servername/reports.
However, they can go to http://servername.companyname.com/reports -
this prompts a login as it is no longer a part of the 'Local
Intranet' (?) - once the log in is successfully the page loads.
So, am I looking at some sort of faulty log in module? Why only 5 of
60 users? These users are spread out throughout the company - there
is no noticeable relation to any existing group policy, or group
membership.
I have used the 'Run As' command to test different client machines.
This does not seem to be client based. If I run as and use two IE
sessions on the same machine the 'faulty' users will fail and the rest
of the users will succeed. If I go to a different machine (I've used
3 so far - all the same result) this behavior chases the user.
Long story short, I'm pretty baffled.
Any help anyone can offer would be greatly appreciated.
Happy to answer any questions that I can.
Fairly certain this is not a client issue, fairly certain this is not
a SSRS issue, seems to be something inside of IIS - or at least that's
my best guess.
Thank you so much,
- Kyle
David Wang
> Hello,
>
> I have a Windows Server 2003 box with IIS 6.0 hosting a website for
> SSRS (sql 2005 reporting services).
>
> and get to the reports server just fine, web server responds, gives
> them what they need, all is good.
>
> Unfortunately, I have a small but growing number that are receiving a
> strange error on IE7 and IE8.
>
> HTTP 400 Bad Request: Invalid Verb
>
> If I understand right this error implies that the client machine was
> able to contact the server (the website is alive) but for whatever
> reason there is a bad (insert unknown component here) causing a
> disconnect?
>
> Anyone have any ideas how I may go about figuring out which component
> is causing this Bad Request Error?
>
> For my clients: The servername is setup as a 'Local Intranet' site.
>
> and it's good to go, it uses integrated windows authentication.
>
>
> However, they can go tohttp://servername.companyname.com/reports-
> this prompts a login as it is no longer a part of the 'Local
> Intranet' (?) - once the log in is successfully the page loads.
>
> So, am I looking at some sort of faulty log in module? Why only 5 of
> 60 users? These users are spread out throughout the company - there
> is no noticeable relation to any existing group policy, or group
> membership.
>
> I have used the 'Run As' command to test different client machines.
> This does not seem to be client based. If I run as and use two IE
> sessions on the same machine the 'faulty' users will fail and the rest
> of the users will succeed. If I go to a different machine (I've used
> 3 so far - all the same result) this behavior chases the user.
>
> Long story short, I'm pretty baffled.
>
> Any help anyone can offer would be greatly appreciated.
>
> Happy to answer any questions that I can.
>
> Fairly certain this is not a client issue, fairly certain this is not
> a SSRS issue, seems to be something inside of IIS - or at least that's
> my best guess.
>
> Thank you so much,
>
> - Kyle
HTTP 400 Bad Request: Invalid Verb -- indicates that the issue is
client-side. The issue is not inside of IIS. It also correlates with
your observation that the issue chases the user and not machine. The
problem is likely how something about the users cause web browsers to
generate a bad request.
1. HTTP Clients are supposed to send request looking like the
following to the web server (web browsers send a lot more; just giving
the bare basics):
GET /reports HTTP/1.1\r\n
Host: servername\r\n
Accept: */*\r\n
\r\n
2. HTTP Servers are supposed to process the request by retrieving the
resource at /reports . Server-side code and configuration determine
what "retrieving" means for a URL of "/reports".
3. HTTP 400 Bad Request: Invalid Verb means that an unrecognized verb
(i.e. the "GET" part of the request) was received by the server
This sort of issue is usually either:
a. the client send a bad verb
b. intervening network device munged the verb
c. improperly demarcated requests in the HTTP stream altered what the
server interprets as the "verb"
a is highly unlikely since that would be a bad web browser bug.
b is possible but you said different users on the same machine came up
with different results so that is not the case here.
c is possible, for example if the users have heavy Domain Group
membership which come up with complicated Kerberos tokens.
I suggest looking at what is common between those 5 users and what is
different between them and the other 55 users. Especially how
authentication impacts them.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
Koenti
IIS 5.1 on Windows XP.
Virtual directories with "integrated windows authentication" enabled give
some users the same HTTP 400 error. If I disable "integrated windows
authentication" and enabled "anonymous authentication" --> pages are loaded.
Does somebody has a solution? Maybe a combination of server and client?
Regards
"David Wang" wrote:
> .
>
Kyle
Thank you very much for the reply - I apologize for the delayed
response on my part.
So far, no resolution on this particular item.
I have tried a few items in/around user accounts to see what I can -
nothing really showing up.
User Group Membership is random. They are now Vice President,
Executive Assistant, Lab Head, Field Representative, 3 Lab
Technicians. The only group membership that applies to all is the
'all users' group. Were this the case/cause it would (I hope) cause
all users to have the same issue (or not have it - ideally). Thereby,
I hesitate to say this is an individual group problem.
Recently two machines were patched (MS patching - iTunes installed on
one iTunes updated on the other - Update from IE6 to IE8 on one -
other was already on IE8) and now these two users are affected by this
same bug - neither was before. The AD group membership for these
users did not change pre/post patching. Thereby - something in the
patch triggered a problem(??? This is inconsistent with the other
behavoirs I've seen)
Made some modifications to groups after the fact - added/removed
(reboot each time to make sure the groups did reset properly) -
attempt to change/modify/reset/something their behavoir - no luck.
If this is user side:
- Why is it that two users can login to the same machine but receive
different results? (it's not client based - its entirley user based?)
- If it is not based on the machine, but on the individual user - how
do I begin to ascertain/track/error log/etc this problem? Also - if
it's based on the user - not the machine - why did the machine
patching cause two new users to be affected?
- ADSIedit perhaps? Is there something buried deep inside of AD that
may help?
I'm still at a bit of a loss. Is this something that Microsoft
support may be able to fix? Should I just give them a ring and setup
a case?
As always, any help is greatly appreciated.
Thank you to eveyrone who takes your time to read through this, and of
course those who respond as well.
- Kyle
Kyle
Finally able to resolve the above error.
Our client side Antivirus software was scanning the headers and,
apparently, re-constructing the headers inappropriately.
Once we put a client side exception for internal website in place -
they all work just beautifully.
In this world of complex threats it seems sometimes an ounce of
prevention can cause a big headache ;)
I'd much rather a headache then a virus threat hitting - oh well.
Problem resolved,
Thank you again for all your help,
- Kyle
Vayu
Thank you for posting the solution.
I have exactly same issue with one of my company internal application
In your solution you said
Once we put a client side exception for internal website in place - they all work just beautifully.
I didn't get what is done to fix the issue.
Can you please explain this fix more.
Thank you in advance.
Kyle wrote:
Good Afternoon,Finally able to resolve the above error.
23-Feb-10
Good Afternoon,
Problem resolved,
- Kyle
Previous Posts In This Thread:
On Wednesday, December 30, 2009 9:10 PM
Kyle wrote:
IIS 6.0 gives some clients HTTP 400 Bad Request but not others?
Hello,
I have a Windows Server 2003 box with IIS 6.0 hosting a website for
SSRS (sql 2005 reporting services).
From the local intranet most clients can use a hyperlink http://servername/reports
and get to the reports server just fine, web server responds, gives
them what they need, all is good.
Unfortunately, I have a small but growing number that are receiving a
strange error on IE7 and IE8.
HTTP 400 Bad Request: Invalid Verb
If I understand right this error implies that the client machine was
able to contact the server (the website is alive) but for whatever
reason there is a bad (insert unknown component here) causing a
disconnect?
Anyone have any ideas how I may go about figuring out which component
is causing this Bad Request Error?
For my clients: The servername is setup as a 'Local Intranet' site.
Most clients (55 of 60) can click on a link to http://servername/reports
and it is good to go, it uses integrated windows authentication.
The other 5 out of 60 get bad request invalid verb from http://servername/reports.
However, they can go to http://servername.companyname.com/reports -
this prompts a login as it is no longer a part of the 'Local
Intranet' (?) - once the log in is successfully the page loads.
So, am I looking at some sort of faulty log in module? Why only 5 of
60 users? These users are spread out throughout the company - there
is no noticeable relation to any existing group policy, or group
membership.
I have used the 'Run As' command to test different client machines.
This does not seem to be client based. If I run as and use two IE
sessions on the same machine the 'faulty' users will fail and the rest
of the users will succeed. If I go to a different machine (I have used
3 so far - all the same result) this behavior chases the user.
Long story short, I am pretty baffled.
Any help anyone can offer would be greatly appreciated.
Happy to answer any questions that I can.
Fairly certain this is not a client issue, fairly certain this is not
a SSRS issue, seems to be something inside of IIS - or at least that is
my best guess.
Thank you so much,
- Kyle
On Thursday, January 07, 2010 3:28 PM
David Wang wrote:
/reportsreports.
/reports
reports.
On Friday, January 08, 2010 6:07 AM
Koenti wrote:
I have the same problem on some IE7 clients.IIS 5.1 on Windows XP.
I have the same problem on some IE7 clients.
IIS 5.1 on Windows XP.
Virtual directories with "integrated windows authentication" enabled give
some users the same HTTP 400 error. If I disable "integrated windows
authentication" and enabled "anonymous authentication" --> pages are loaded.
Does somebody has a solution? Maybe a combination of server and client?
Regards
"David Wang" wrote:
On Friday, February 19, 2010 12:58 PM
Kyle wrote:
Good Afternoon,Thank you very much for the reply - I apologize for the
Good Afternoon,
Thank you very much for the reply - I apologize for the delayed
response on my part.
So far, no resolution on this particular item.
I have tried a few items in/around user accounts to see what I can -
nothing really showing up.
User Group Membership is random. They are now Vice President,
Executive Assistant, Lab Head, Field Representative, 3 Lab
Technicians. The only group membership that applies to all is the
'all users' group. Were this the case/cause it would (I hope) cause
all users to have the same issue (or not have it - ideally). Thereby,
I hesitate to say this is an individual group problem.
Recently two machines were patched (MS patching - iTunes installed on
one iTunes updated on the other - Update from IE6 to IE8 on one -
other was already on IE8) and now these two users are affected by this
same bug - neither was before. The AD group membership for these
users did not change pre/post patching. Thereby - something in the
patch triggered a problem(??? This is inconsistent with the other
behavoirs I have seen)
Made some modifications to groups after the fact - added/removed
(reboot each time to make sure the groups did reset properly) -
attempt to change/modify/reset/something their behavoir - no luck.
If this is user side:
- Why is it that two users can login to the same machine but receive
different results? (it is not client based - its entirley user based?)
- If it is not based on the machine, but on the individual user - how
do I begin to ascertain/track/error log/etc this problem? Also - if
it is based on the user - not the machine - why did the machine
patching cause two new users to be affected?
- ADSIedit perhaps? Is there isomething buried deep inside of AD that
may help?
I am still at a bit of a loss. Is this something that Microsoft
support may be able to fix? Should I just give them a ring and setup
a case?
As always, any help is greatly appreciated.
Thank you to eveyrone who takes your time to read through this, and of
course those who respond as well.
- Kyle
On Tuesday, February 23, 2010 6:12 PM
Kyle wrote:
Good Afternoon,Finally able to resolve the above error.
Good Afternoon,
Problem resolved,
- Kyle
Submitted via EggHeadCafe - Software Developer Portal of Choice
Free Online Courses Available for Eggheadcafe.com Users
http://www.eggheadcafe.com/tutorials/aspnet/5261083e-6e03-4b25-8728-fc3cf6855293/free-online-courses-avail.aspx
cnyalkal Nyalkalkar
Thanks for such a pinpointed discussion.
I have exactly the same situation.
Could you please elaborate what you meant by
'Once we put a client side exception for internal website in place '
I am really struggling for a solution for this problem from years...
Thanks a lot in advance...
>>>>>> On Wednesday, May 12, 2010 11:01 AM Vayu wrote:
>>>>>> Thank you for posting the solution.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have exactly same issue with one of my company internal application
>>>>>>
>>>>>>
>>>>>>
>>>>>> In your solution you said
>>>>>>
>>>>>>
>>>>>>
>>>>>> Once we put a client side exception for internal website in place - they all work just beautifully.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I didn't get what is done to fix the issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you please explain this fix more.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you in advance.
>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>>> Using the ASP.NET CustomValidator Control
>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/e622d48f-2787-4906-b97f-1ef8037a688f/using-the-aspnet-customvalidator-control.aspx
www.na...@gmail.com
I am struggling to do a POST request to a IIS server which is ment for issuing WebToken while doing windows office 365 authentication. However the matter of the interest is that when I am doing POST operation on this particular server using windows as my client environment, i receive INVALID VERB - HTTP 400 error. However, when I use linux, everything looks perfect. I even disabled the antivirus and firewall on my computer just to find that still there is no change in the response from the server.
I shall be grateful to you if you can share the fix with me so that I can stop breaking my head for this and take a step further.
Regards,
Naval.