HTTP 400 Bad Request

HTTP 400 Bad Request

am 11.03.2006 04:27:29 von Graham

When connecting to our web server (IIS 6.0, Windows 2003 Server), we have
some users that can only connect via IP address. When they attempt to
connect using the servername, they receive a HTTP 400 Bad Request error. We
have verified that DNS is correct and that it's not a permission issue (or at
least we think it's not permission since they can connect via IP address).
All clients are using IE. There did not appear to be any logs generated on
the server. A sniff of the traffic did show that the request was making it
to the server.

Here's a overview of what we are seeing for two users on the same machine.

User A logs in.
-Can access the web site using the hostname
-Can access the web site using IP address
-Using WFetch generates a HTTP 400 Bad Request error

User B logs in.
-Cannot access the website using the hostname
-Can access the website using the IP address
-Using WFetch generates a HTTP 400 Bad Request error

Has anyone seen this type of problem?

Thanks for your help.

Re: HTTP 400 Bad Request

am 11.03.2006 04:36:47 von someone

Still seems like DNS issue to me since IP works for both users.

HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
errors never make it to user mode and hence not in
%SystemRoot%\System32\LogFiles\W3SVC#\*.log

http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Graham" wrote in message
news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
> When connecting to our web server (IIS 6.0, Windows 2003 Server), we have
> some users that can only connect via IP address. When they attempt to
> connect using the servername, they receive a HTTP 400 Bad Request error.
> We
> have verified that DNS is correct and that it's not a permission issue (or
> at
> least we think it's not permission since they can connect via IP address).
> All clients are using IE. There did not appear to be any logs generated
> on
> the server. A sniff of the traffic did show that the request was making
> it
> to the server.
>
> Here's a overview of what we are seeing for two users on the same machine.
>
> User A logs in.
> -Can access the web site using the hostname
> -Can access the web site using IP address
> -Using WFetch generates a HTTP 400 Bad Request error
>
> User B logs in.
> -Cannot access the website using the hostname
> -Can access the website using the IP address
> -Using WFetch generates a HTTP 400 Bad Request error
>
> Has anyone seen this type of problem?
>
> Thanks for your help.

Re: HTTP 400 Bad Request

am 11.03.2006 19:56:27 von Graham

David - I may not fully understand DNS, but if it was a DNS issue, why would
some users still be able to resolve the hostname? When we performed our
test, User A logged in and then User B opened IE using "runas". (roaming
profiles are enabled)

I should also add that using WFetch with either IP or hostname results in a
HTTP 400 error for both users on the same machine. Sometimea WFetch will
generate a HTTP 401 error, not sure why.

Does the HTTP 400 error always get logged? I did check the HTTP.SYS error
log but did not see any 400 errors, only the 401 errors.

"David Wang [Msft]" wrote:

> Still seems like DNS issue to me since IP works for both users.
>
> HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
> errors never make it to user mode and hence not in
> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
>
> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
>
> "Graham" wrote in message
> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
> > When connecting to our web server (IIS 6.0, Windows 2003 Server), we have
> > some users that can only connect via IP address. When they attempt to
> > connect using the servername, they receive a HTTP 400 Bad Request error.
> > We
> > have verified that DNS is correct and that it's not a permission issue (or
> > at
> > least we think it's not permission since they can connect via IP address).
> > All clients are using IE. There did not appear to be any logs generated
> > on
> > the server. A sniff of the traffic did show that the request was making
> > it
> > to the server.
> >
> > Here's a overview of what we are seeing for two users on the same machine.
> >
> > User A logs in.
> > -Can access the web site using the hostname
> > -Can access the web site using IP address
> > -Using WFetch generates a HTTP 400 Bad Request error
> >
> > User B logs in.
> > -Cannot access the website using the hostname
> > -Can access the website using the IP address
> > -Using WFetch generates a HTTP 400 Bad Request error
> >
> > Has anyone seen this type of problem?
> >
> > Thanks for your help.
>
>
>

Re: HTTP 400 Bad Request

am 12.03.2006 07:37:58 von someone

If it was an IIS issue, then things wouldn't even work by IP. Since you say
it works by IP, it pretty much moves IIS out of the picture.

If the 400 error came from the IIS server, then it would be in HTTP.SYS
error log. If it is not in the HTTP.SYS error log you are either looking at
a serious HTTP.SYS bug or some other network device between the
client/server introducing different behavior. Given the odd set of
behaviors, I am more inclined to believe there is some other network device
introducing unexplained behaviors.

DNS issues doesn't have to be with the DNS server; it can be from the client
not using the DNS server you think it should. Basically, since DNS is
supposed to translate name into IP:Host, if the server side is configured
correctly (which I presume, since other users can use name just fine), it is
up to the client to come up with the right IP:Host on the request.

Showing the network sniff of the entire request from the server's network
card would be useful information. As well as the associated HTTP 400 error
entry in HTTPERR*.log if you get a 400 response.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Graham" wrote in message
news:707776CD-E51C-42FD-A564-A5AC258C7607@microsoft.com...
> David - I may not fully understand DNS, but if it was a DNS issue, why
> would
> some users still be able to resolve the hostname? When we performed our
> test, User A logged in and then User B opened IE using "runas". (roaming
> profiles are enabled)
>
> I should also add that using WFetch with either IP or hostname results in
> a
> HTTP 400 error for both users on the same machine. Sometimea WFetch will
> generate a HTTP 401 error, not sure why.
>
> Does the HTTP 400 error always get logged? I did check the HTTP.SYS error
> log but did not see any 400 errors, only the 401 errors.
>
> "David Wang [Msft]" wrote:
>
>> Still seems like DNS issue to me since IP works for both users.
>>
>> HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
>> errors never make it to user mode and hence not in
>> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
>>
>> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
>>
>> --
>> //David
>> IIS
>> http://blogs.msdn.com/David.Wang
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> //
>>
>> "Graham" wrote in message
>> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
>> > When connecting to our web server (IIS 6.0, Windows 2003 Server), we
>> > have
>> > some users that can only connect via IP address. When they attempt to
>> > connect using the servername, they receive a HTTP 400 Bad Request
>> > error.
>> > We
>> > have verified that DNS is correct and that it's not a permission issue
>> > (or
>> > at
>> > least we think it's not permission since they can connect via IP
>> > address).
>> > All clients are using IE. There did not appear to be any logs
>> > generated
>> > on
>> > the server. A sniff of the traffic did show that the request was
>> > making
>> > it
>> > to the server.
>> >
>> > Here's a overview of what we are seeing for two users on the same
>> > machine.
>> >
>> > User A logs in.
>> > -Can access the web site using the hostname
>> > -Can access the web site using IP address
>> > -Using WFetch generates a HTTP 400 Bad Request error
>> >
>> > User B logs in.
>> > -Cannot access the website using the hostname
>> > -Can access the website using the IP address
>> > -Using WFetch generates a HTTP 400 Bad Request error
>> >
>> > Has anyone seen this type of problem?
>> >
>> > Thanks for your help.
>>
>>
>>

Re: HTTP 400 Bad Request

am 13.03.2006 17:25:21 von Graham

David -
Here's a copy of the HTTPErr.log file

2006-03-13 13:24:14 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 HTTP/1.1 GET /
400 - RequestLength
2006-03-13 13:24:35 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 - - - - -
Timer_MinBytesPerSecond


It doesn't matter what address I try to navigate to (a site that exists or
one that does not exist on the server), they all genereate a HTTP 400 error.


"David Wang [Msft]" wrote:

> If it was an IIS issue, then things wouldn't even work by IP. Since you say
> it works by IP, it pretty much moves IIS out of the picture.
>
> If the 400 error came from the IIS server, then it would be in HTTP.SYS
> error log. If it is not in the HTTP.SYS error log you are either looking at
> a serious HTTP.SYS bug or some other network device between the
> client/server introducing different behavior. Given the odd set of
> behaviors, I am more inclined to believe there is some other network device
> introducing unexplained behaviors.
>
> DNS issues doesn't have to be with the DNS server; it can be from the client
> not using the DNS server you think it should. Basically, since DNS is
> supposed to translate name into IP:Host, if the server side is configured
> correctly (which I presume, since other users can use name just fine), it is
> up to the client to come up with the right IP:Host on the request.
>
> Showing the network sniff of the entire request from the server's network
> card would be useful information. As well as the associated HTTP 400 error
> entry in HTTPERR*.log if you get a 400 response.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
>
> "Graham" wrote in message
> news:707776CD-E51C-42FD-A564-A5AC258C7607@microsoft.com...
> > David - I may not fully understand DNS, but if it was a DNS issue, why
> > would
> > some users still be able to resolve the hostname? When we performed our
> > test, User A logged in and then User B opened IE using "runas". (roaming
> > profiles are enabled)
> >
> > I should also add that using WFetch with either IP or hostname results in
> > a
> > HTTP 400 error for both users on the same machine. Sometimea WFetch will
> > generate a HTTP 401 error, not sure why.
> >
> > Does the HTTP 400 error always get logged? I did check the HTTP.SYS error
> > log but did not see any 400 errors, only the 401 errors.
> >
> > "David Wang [Msft]" wrote:
> >
> >> Still seems like DNS issue to me since IP works for both users.
> >>
> >> HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
> >> errors never make it to user mode and hence not in
> >> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
> >>
> >> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
> >>
> >> --
> >> //David
> >> IIS
> >> http://blogs.msdn.com/David.Wang
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >> //
> >>
> >> "Graham" wrote in message
> >> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
> >> > When connecting to our web server (IIS 6.0, Windows 2003 Server), we
> >> > have
> >> > some users that can only connect via IP address. When they attempt to
> >> > connect using the servername, they receive a HTTP 400 Bad Request
> >> > error.
> >> > We
> >> > have verified that DNS is correct and that it's not a permission issue
> >> > (or
> >> > at
> >> > least we think it's not permission since they can connect via IP
> >> > address).
> >> > All clients are using IE. There did not appear to be any logs
> >> > generated
> >> > on
> >> > the server. A sniff of the traffic did show that the request was
> >> > making
> >> > it
> >> > to the server.
> >> >
> >> > Here's a overview of what we are seeing for two users on the same
> >> > machine.
> >> >
> >> > User A logs in.
> >> > -Can access the web site using the hostname
> >> > -Can access the web site using IP address
> >> > -Using WFetch generates a HTTP 400 Bad Request error
> >> >
> >> > User B logs in.
> >> > -Cannot access the website using the hostname
> >> > -Can access the website using the IP address
> >> > -Using WFetch generates a HTTP 400 Bad Request error
> >> >
> >> > Has anyone seen this type of problem?
> >> >
> >> > Thanks for your help.
> >>
> >>
> >>
>
>
>

Re: HTTP 400 Bad Request

am 14.03.2006 08:45:08 von someone

Get a network sniff of requests that work and requests that don't.

400 RequestLength, as documented, means a request length limit was hit. You
want to get a network trace of that request to see why.

One possibility I am mentioning -- if you are using Integrated
authentication and it negotiates Kerberos, it is possible to end up with
very large Kerberos tickets that hit request header limits and require
server reconfiguration - depends on your domain setup. If this is the case,
maybe when users use IP it is not negotiating Kerberos and thus "works", and
maybe other users have smaller Kerberos tickets so they work with hostname.
As always, the limits are compromise between security and functionality, so
you just need to figure out which is worth more and consciously make the
decisions.

You need to troubleshoot by looking at the failure and deducing
possibilities. Just saying it fails for a site that exists or does not exist
is not useful when looking at 400. You want to figure out *why* so you can
fix it.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Graham" wrote in message
news:B76E57DF-8547-4DAE-BC0F-47C06C5B0793@microsoft.com...
> David -
> Here's a copy of the HTTPErr.log file
>
> 2006-03-13 13:24:14 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 HTTP/1.1 GET /
> 400 - RequestLength
> 2006-03-13 13:24:35 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 - - - - -
> Timer_MinBytesPerSecond
>
>
> It doesn't matter what address I try to navigate to (a site that exists or
> one that does not exist on the server), they all genereate a HTTP 400
> error.
>
>
> "David Wang [Msft]" wrote:
>
>> If it was an IIS issue, then things wouldn't even work by IP. Since you
>> say
>> it works by IP, it pretty much moves IIS out of the picture.
>>
>> If the 400 error came from the IIS server, then it would be in HTTP.SYS
>> error log. If it is not in the HTTP.SYS error log you are either looking
>> at
>> a serious HTTP.SYS bug or some other network device between the
>> client/server introducing different behavior. Given the odd set of
>> behaviors, I am more inclined to believe there is some other network
>> device
>> introducing unexplained behaviors.
>>
>> DNS issues doesn't have to be with the DNS server; it can be from the
>> client
>> not using the DNS server you think it should. Basically, since DNS is
>> supposed to translate name into IP:Host, if the server side is configured
>> correctly (which I presume, since other users can use name just fine), it
>> is
>> up to the client to come up with the right IP:Host on the request.
>>
>> Showing the network sniff of the entire request from the server's network
>> card would be useful information. As well as the associated HTTP 400
>> error
>> entry in HTTPERR*.log if you get a 400 response.
>>
>> --
>> //David
>> IIS
>> http://blogs.msdn.com/David.Wang
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> //
>>
>> "Graham" wrote in message
>> news:707776CD-E51C-42FD-A564-A5AC258C7607@microsoft.com...
>> > David - I may not fully understand DNS, but if it was a DNS issue, why
>> > would
>> > some users still be able to resolve the hostname? When we performed
>> > our
>> > test, User A logged in and then User B opened IE using "runas".
>> > (roaming
>> > profiles are enabled)
>> >
>> > I should also add that using WFetch with either IP or hostname results
>> > in
>> > a
>> > HTTP 400 error for both users on the same machine. Sometimea WFetch
>> > will
>> > generate a HTTP 401 error, not sure why.
>> >
>> > Does the HTTP 400 error always get logged? I did check the HTTP.SYS
>> > error
>> > log but did not see any 400 errors, only the 401 errors.
>> >
>> > "David Wang [Msft]" wrote:
>> >
>> >> Still seems like DNS issue to me since IP works for both users.
>> >>
>> >> HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
>> >> errors never make it to user mode and hence not in
>> >> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
>> >>
>> >> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
>> >>
>> >> --
>> >> //David
>> >> IIS
>> >> http://blogs.msdn.com/David.Wang
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >> //
>> >>
>> >> "Graham" wrote in message
>> >> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
>> >> > When connecting to our web server (IIS 6.0, Windows 2003 Server), we
>> >> > have
>> >> > some users that can only connect via IP address. When they attempt
>> >> > to
>> >> > connect using the servername, they receive a HTTP 400 Bad Request
>> >> > error.
>> >> > We
>> >> > have verified that DNS is correct and that it's not a permission
>> >> > issue
>> >> > (or
>> >> > at
>> >> > least we think it's not permission since they can connect via IP
>> >> > address).
>> >> > All clients are using IE. There did not appear to be any logs
>> >> > generated
>> >> > on
>> >> > the server. A sniff of the traffic did show that the request was
>> >> > making
>> >> > it
>> >> > to the server.
>> >> >
>> >> > Here's a overview of what we are seeing for two users on the same
>> >> > machine.
>> >> >
>> >> > User A logs in.
>> >> > -Can access the web site using the hostname
>> >> > -Can access the web site using IP address
>> >> > -Using WFetch generates a HTTP 400 Bad Request error
>> >> >
>> >> > User B logs in.
>> >> > -Cannot access the website using the hostname
>> >> > -Can access the website using the IP address
>> >> > -Using WFetch generates a HTTP 400 Bad Request error
>> >> >
>> >> > Has anyone seen this type of problem?
>> >> >
>> >> > Thanks for your help.
>> >>
>> >>
>> >>
>>
>>
>>

Re: HTTP 400 Bad Request

am 14.03.2006 23:41:02 von Graham

Our problem was resolved when we added the MaxFieldLength and MaxRequestBytes
registry keys under the HTTP parameters key.

Problem appears to be affecting users who are members of a large number of
groups.

"David Wang [Msft]" wrote:

> Get a network sniff of requests that work and requests that don't.
>
> 400 RequestLength, as documented, means a request length limit was hit. You
> want to get a network trace of that request to see why.
>
> One possibility I am mentioning -- if you are using Integrated
> authentication and it negotiates Kerberos, it is possible to end up with
> very large Kerberos tickets that hit request header limits and require
> server reconfiguration - depends on your domain setup. If this is the case,
> maybe when users use IP it is not negotiating Kerberos and thus "works", and
> maybe other users have smaller Kerberos tickets so they work with hostname.
> As always, the limits are compromise between security and functionality, so
> you just need to figure out which is worth more and consciously make the
> decisions.
>
> You need to troubleshoot by looking at the failure and deducing
> possibilities. Just saying it fails for a site that exists or does not exist
> is not useful when looking at 400. You want to figure out *why* so you can
> fix it.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
>
> "Graham" wrote in message
> news:B76E57DF-8547-4DAE-BC0F-47C06C5B0793@microsoft.com...
> > David -
> > Here's a copy of the HTTPErr.log file
> >
> > 2006-03-13 13:24:14 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 HTTP/1.1 GET /
> > 400 - RequestLength
> > 2006-03-13 13:24:35 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 - - - - -
> > Timer_MinBytesPerSecond
> >
> >
> > It doesn't matter what address I try to navigate to (a site that exists or
> > one that does not exist on the server), they all genereate a HTTP 400
> > error.
> >
> >
> > "David Wang [Msft]" wrote:
> >
> >> If it was an IIS issue, then things wouldn't even work by IP. Since you
> >> say
> >> it works by IP, it pretty much moves IIS out of the picture.
> >>
> >> If the 400 error came from the IIS server, then it would be in HTTP.SYS
> >> error log. If it is not in the HTTP.SYS error log you are either looking
> >> at
> >> a serious HTTP.SYS bug or some other network device between the
> >> client/server introducing different behavior. Given the odd set of
> >> behaviors, I am more inclined to believe there is some other network
> >> device
> >> introducing unexplained behaviors.
> >>
> >> DNS issues doesn't have to be with the DNS server; it can be from the
> >> client
> >> not using the DNS server you think it should. Basically, since DNS is
> >> supposed to translate name into IP:Host, if the server side is configured
> >> correctly (which I presume, since other users can use name just fine), it
> >> is
> >> up to the client to come up with the right IP:Host on the request.
> >>
> >> Showing the network sniff of the entire request from the server's network
> >> card would be useful information. As well as the associated HTTP 400
> >> error
> >> entry in HTTPERR*.log if you get a 400 response.
> >>
> >> --
> >> //David
> >> IIS
> >> http://blogs.msdn.com/David.Wang
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >> //
> >>
> >> "Graham" wrote in message
> >> news:707776CD-E51C-42FD-A564-A5AC258C7607@microsoft.com...
> >> > David - I may not fully understand DNS, but if it was a DNS issue, why
> >> > would
> >> > some users still be able to resolve the hostname? When we performed
> >> > our
> >> > test, User A logged in and then User B opened IE using "runas".
> >> > (roaming
> >> > profiles are enabled)
> >> >
> >> > I should also add that using WFetch with either IP or hostname results
> >> > in
> >> > a
> >> > HTTP 400 error for both users on the same machine. Sometimea WFetch
> >> > will
> >> > generate a HTTP 401 error, not sure why.
> >> >
> >> > Does the HTTP 400 error always get logged? I did check the HTTP.SYS
> >> > error
> >> > log but did not see any 400 errors, only the 401 errors.
> >> >
> >> > "David Wang [Msft]" wrote:
> >> >
> >> >> Still seems like DNS issue to me since IP works for both users.
> >> >>
> >> >> HTTPERR.LOG should give details on the reason for 400 Bad Request. 400
> >> >> errors never make it to user mode and hence not in
> >> >> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
> >> >>
> >> >> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
> >> >>
> >> >> --
> >> >> //David
> >> >> IIS
> >> >> http://blogs.msdn.com/David.Wang
> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.
> >> >> //
> >> >>
> >> >> "Graham" wrote in message
> >> >> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
> >> >> > When connecting to our web server (IIS 6.0, Windows 2003 Server), we
> >> >> > have
> >> >> > some users that can only connect via IP address. When they attempt
> >> >> > to
> >> >> > connect using the servername, they receive a HTTP 400 Bad Request
> >> >> > error.
> >> >> > We
> >> >> > have verified that DNS is correct and that it's not a permission
> >> >> > issue
> >> >> > (or
> >> >> > at
> >> >> > least we think it's not permission since they can connect via IP
> >> >> > address).
> >> >> > All clients are using IE. There did not appear to be any logs
> >> >> > generated
> >> >> > on
> >> >> > the server. A sniff of the traffic did show that the request was
> >> >> > making
> >> >> > it
> >> >> > to the server.
> >> >> >
> >> >> > Here's a overview of what we are seeing for two users on the same
> >> >> > machine.
> >> >> >
> >> >> > User A logs in.
> >> >> > -Can access the web site using the hostname
> >> >> > -Can access the web site using IP address
> >> >> > -Using WFetch generates a HTTP 400 Bad Request error
> >> >> >
> >> >> > User B logs in.
> >> >> > -Cannot access the website using the hostname
> >> >> > -Can access the website using the IP address
> >> >> > -Using WFetch generates a HTTP 400 Bad Request error
> >> >> >
> >> >> > Has anyone seen this type of problem?
> >> >> >
> >> >> > Thanks for your help.
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Re: HTTP 400 Bad Request

am 15.03.2006 12:10:39 von someone

Ah, then you are seeing the Kerberos ticket size issue I mentioned.

Yes, in those cases the Kerberos ticket, which is passed in the request
header, gets large and either fails the default 10K MaxFieldLength or
default 16K MaxRequestBytes field. You have to adjust those two HTTP.SYS
parameters for this case.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Graham" wrote in message
news:3D888F81-84A7-4755-8CA0-491639B985A3@microsoft.com...
> Our problem was resolved when we added the MaxFieldLength and
> MaxRequestBytes
> registry keys under the HTTP parameters key.
>
> Problem appears to be affecting users who are members of a large number of
> groups.
>
> "David Wang [Msft]" wrote:
>
>> Get a network sniff of requests that work and requests that don't.
>>
>> 400 RequestLength, as documented, means a request length limit was hit.
>> You
>> want to get a network trace of that request to see why.
>>
>> One possibility I am mentioning -- if you are using Integrated
>> authentication and it negotiates Kerberos, it is possible to end up with
>> very large Kerberos tickets that hit request header limits and require
>> server reconfiguration - depends on your domain setup. If this is the
>> case,
>> maybe when users use IP it is not negotiating Kerberos and thus "works",
>> and
>> maybe other users have smaller Kerberos tickets so they work with
>> hostname.
>> As always, the limits are compromise between security and functionality,
>> so
>> you just need to figure out which is worth more and consciously make the
>> decisions.
>>
>> You need to troubleshoot by looking at the failure and deducing
>> possibilities. Just saying it fails for a site that exists or does not
>> exist
>> is not useful when looking at 400. You want to figure out *why* so you
>> can
>> fix it.
>>
>> --
>> //David
>> IIS
>> http://blogs.msdn.com/David.Wang
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> //
>>
>> "Graham" wrote in message
>> news:B76E57DF-8547-4DAE-BC0F-47C06C5B0793@microsoft.com...
>> > David -
>> > Here's a copy of the HTTPErr.log file
>> >
>> > 2006-03-13 13:24:14 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 HTTP/1.1
>> > GET /
>> > 400 - RequestLength
>> > 2006-03-13 13:24:35 aaa.bbb.ccc.ddd 4108 aaa.bbb.ccc.ddd 80 - - - - -
>> > Timer_MinBytesPerSecond
>> >
>> >
>> > It doesn't matter what address I try to navigate to (a site that exists
>> > or
>> > one that does not exist on the server), they all genereate a HTTP 400
>> > error.
>> >
>> >
>> > "David Wang [Msft]" wrote:
>> >
>> >> If it was an IIS issue, then things wouldn't even work by IP. Since
>> >> you
>> >> say
>> >> it works by IP, it pretty much moves IIS out of the picture.
>> >>
>> >> If the 400 error came from the IIS server, then it would be in
>> >> HTTP.SYS
>> >> error log. If it is not in the HTTP.SYS error log you are either
>> >> looking
>> >> at
>> >> a serious HTTP.SYS bug or some other network device between the
>> >> client/server introducing different behavior. Given the odd set of
>> >> behaviors, I am more inclined to believe there is some other network
>> >> device
>> >> introducing unexplained behaviors.
>> >>
>> >> DNS issues doesn't have to be with the DNS server; it can be from the
>> >> client
>> >> not using the DNS server you think it should. Basically, since DNS is
>> >> supposed to translate name into IP:Host, if the server side is
>> >> configured
>> >> correctly (which I presume, since other users can use name just fine),
>> >> it
>> >> is
>> >> up to the client to come up with the right IP:Host on the request.
>> >>
>> >> Showing the network sniff of the entire request from the server's
>> >> network
>> >> card would be useful information. As well as the associated HTTP 400
>> >> error
>> >> entry in HTTPERR*.log if you get a 400 response.
>> >>
>> >> --
>> >> //David
>> >> IIS
>> >> http://blogs.msdn.com/David.Wang
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >> //
>> >>
>> >> "Graham" wrote in message
>> >> news:707776CD-E51C-42FD-A564-A5AC258C7607@microsoft.com...
>> >> > David - I may not fully understand DNS, but if it was a DNS issue,
>> >> > why
>> >> > would
>> >> > some users still be able to resolve the hostname? When we performed
>> >> > our
>> >> > test, User A logged in and then User B opened IE using "runas".
>> >> > (roaming
>> >> > profiles are enabled)
>> >> >
>> >> > I should also add that using WFetch with either IP or hostname
>> >> > results
>> >> > in
>> >> > a
>> >> > HTTP 400 error for both users on the same machine. Sometimea WFetch
>> >> > will
>> >> > generate a HTTP 401 error, not sure why.
>> >> >
>> >> > Does the HTTP 400 error always get logged? I did check the HTTP.SYS
>> >> > error
>> >> > log but did not see any 400 errors, only the 401 errors.
>> >> >
>> >> > "David Wang [Msft]" wrote:
>> >> >
>> >> >> Still seems like DNS issue to me since IP works for both users.
>> >> >>
>> >> >> HTTPERR.LOG should give details on the reason for 400 Bad Request.
>> >> >> 400
>> >> >> errors never make it to user mode and hence not in
>> >> >> %SystemRoot%\System32\LogFiles\W3SVC#\*.log
>> >> >>
>> >> >> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.aspx
>> >> >>
>> >> >> --
>> >> >> //David
>> >> >> IIS
>> >> >> http://blogs.msdn.com/David.Wang
>> >> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> >> rights.
>> >> >> //
>> >> >>
>> >> >> "Graham" wrote in message
>> >> >> news:A888A689-FFDD-41C8-B849-AB9FFF50EBD1@microsoft.com...
>> >> >> > When connecting to our web server (IIS 6.0, Windows 2003 Server),
>> >> >> > we
>> >> >> > have
>> >> >> > some users that can only connect via IP address. When they
>> >> >> > attempt
>> >> >> > to
>> >> >> > connect using the servername, they receive a HTTP 400 Bad Request
>> >> >> > error.
>> >> >> > We
>> >> >> > have verified that DNS is correct and that it's not a permission
>> >> >> > issue
>> >> >> > (or
>> >> >> > at
>> >> >> > least we think it's not permission since they can connect via IP
>> >> >> > address).
>> >> >> > All clients are using IE. There did not appear to be any logs
>> >> >> > generated
>> >> >> > on
>> >> >> > the server. A sniff of the traffic did show that the request was
>> >> >> > making
>> >> >> > it
>> >> >> > to the server.
>> >> >> >
>> >> >> > Here's a overview of what we are seeing for two users on the same
>> >> >> > machine.
>> >> >> >
>> >> >> > User A logs in.
>> >> >> > -Can access the web site using the hostname
>> >> >> > -Can access the web site using IP address
>> >> >> > -Using WFetch generates a HTTP 400 Bad Request error
>> >> >> >
>> >> >> > User B logs in.
>> >> >> > -Cannot access the website using the hostname
>> >> >> > -Can access the website using the IP address
>> >> >> > -Using WFetch generates a HTTP 400 Bad Request error
>> >> >> >
>> >> >> > Has anyone seen this type of problem?
>> >> >> >
>> >> >> > Thanks for your help.
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>