Article ID: 955585 - Last Review: September 30, 2009 - Revision: 2.0

CLM: HTTP Bad Request (Request header too long)

Expand all | Collapse all
Source: Microsoft Support

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

Action

Customer is unable to perform all operations in the CLM portal.

Result

  • With friendly http error messages enabled in Internet Explorer, HTTP 400 errors will be returned in response to web requests being sent to the Internet Information Services (IIS) server.
  • With friendly http error messages disabled in Internet Explorer, the following error message is returned to the user:

    Bad Request (Request header too long)

Cause



The HTTP request that was sent to the IIS server had a request header that exceeded the allowable request header length configured on the IIS server. Specifically, the Authorization header contained a very large Kerberos authentication ticket. The kerberos ticket was so large because the user is a member of many groups in Active Directory.

For security purposes, the HTTP.sys component on the IIS server rejects the incoming HTTP request because it exceeds the configured size limits.

Resolution



Configure the HTTP registry keys MaxFieldLength and MaxRequestBytes on the IIS server to allow for larger request header sizes.

IMPORTANT: Changing these registry keys is considered extremely dangerous. Increasing these keys' values will cause HTTP.sys to use more memory and may increase vulnerability to malicious attacks. If changing these keys is your only option, do not set their values larger than they need to be. Information on determining how large the request headers are and therefore what value to set the registry keys is found later in this article.

For more information on the HTTP.sys registry keys for IIS, please see the following article:

Http.sys registry settings for IIS (http://support.microsoft.com/kb/820129/en-us (http://support.microsoft.com/kb/820129/en-us) )

For more information on HTTP.sys error logging, please see the following article:

Error logging in HTTP API (http://support.microsoft.com/?id=820729 (http://support.microsoft.com/?id=820729) )

More Information



To determine the actual HTTP request size, it can be helpful to use a network monitor trace.  With this trace, we can calculate the size of the http request and compare it against the setting on the IIS server.

 

It is also useful to consult the HTTP.sys error log for information. 

Location: %windir%\system32\logfiles\HTTPERR\httperrX.log

 

Determining HTTP Request Size

The key to resolving this particular problem, was to show that CLM was trying to send a HTTP request to the server that is greater than either the default value of 16k, or greater than the custom setting in their MaxFieldLength & MaxRequestBytes.  To do this, we can use a combination of:

1.    Network monitor  trace

2.    Looking through the http.sys error log located in:

a.    %windir%\system32\logfiles\HTTPERR\httperrX.log.

Example Entry from the httperrX.log:

 

date time c-ip c-port s-ip s-port cs-version cs-method cs-uri sc-status s-siteid s-reason s-queuename

 

2007-04-12 07:37:51 10.201.25.27 1682 10.248.10.65 80 HTTP/1.1 GET /clm 400 - RequestLength –

In the netmon trace, to determine how large the HTTP request is, use the following steps:

 

Netmon3:

=======

1.    Locate the frame that submits an HTTP Get statement

2.    Add the TCP Len value for each frame from the HTTP Get statement until the IIS server returns an ACK

This will be the size of the HTTP request.

Example:

28209    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: Request, GET /CLM/content/sm/requests/SubscriberPrintDocuments.aspx

28210    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28210    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28211    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28212    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28213    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28214    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28215    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28216    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28217    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28218    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28219    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

28220    19:13:04.041       53.906250                            Client     Server     HTTP     HTTP: HTTP Payload

 

Each of the above will have a detail line similar to the following:

Tcp: Flags=....A..., SrcPort=3281, DstPort=HTTP(80), Len=1460, Seq=3225410770 - 3225412230, Ack=1377780890, Win=33580 (scale factor 0) = 0

 

In this example, the HTTP request size was somewhere around 17000, which is more than the default maximum.

 

WireShark:

========

1.       Locate the frame that submits the HTTP Get statement

2.       View the tab at the bottom of the WireShark screen titled “Reassembled TCP” and the number beside this will be the size of the reassembled HTTP request.

 

 

DISCLAIMER

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.

APPLIES TO
  • Microsoft Internet Information Services 6.0
Keywords: 
kbrapidpub kbnomt KB955585