Datasheet

The sequence 1234567890 is repeated 26 times in the URL. Because the path segment is exactly 260
characters though,
http.sys does not reject the request. Instead, this URL results in a 404 from IIS
because there is no
foo.htm file on the system.
However, if you add one more character to this sequence, thus making the path segment 261 characters
long, an HTTP 400 - Bad Request error message is returned. In this case, the request never makes it far
enough for IIS to attempt to find a file called
foo.htm. Instead, http.sys rejects the URL and additional
IIS processing never occurs. This type of URL restriction reduces the load on IIS6, because IIS6 does not
have to waste processor cycles attempting to parse and process a bogus URL.
This raises the question of how a web server administrator can track URL requests are being rejected.
The
http.sys driver will log all errors (not just security-related errors) to a special HTTP error log file.
On Windows Server 2003, inside of the
%windir%\system32\LogFiles directory, there is an HTTPERR
subdirectory. Inside of the directory one or more log files contain errors that were trapped by http.sys.
In the case of the rejected URLs, a log entry looks like:
2005-03-13 22:09:50 127.0.0.1 1302 127.0.0.1 80 HTTP/1.1 GET /1234567890....htm 400
- URL
For brevity the remainder of the GET URL has been snipped in the previous example; however, the log
file will contain the first 4096 bytes of the requested URL. In this example, the value
URL at the end of the
log entry indicates that parsing of the URL failed because one of the path segment restrictions was
exceeded.
If the URL is larger than 16KB, the log entry ends with
URL_Length, indicating that the allowable URL
length had been exceeded. An example of such a log entry is:
2005-03-13 23:02:53 127.0.0.1 1086 127.0.0.1 80 HTTP/0.0 GET - 414 -
URL_Length
For brevity, the URL that caused this is not included because a 16KB long URL would not be particularly
interesting to slog through. Remember that form posts and file uploads also include a message body that
usually contains the vast majority of the content being sent to the web server. Because
http.sys only
checks the URL and associated headers, it does not perform any validation on the size of the message
body. Instead it is ASP.NET that is responsible for limiting the size of raw form post data or file uploads.
A subtle point about the previous discussion is that some of the restrictions
http.sys enforces are based
on number of characters, while other restrictions are based on byte size. In the case of path segments, the
restrictions are based on number of characters, regardless of the underlying character set. However, for
the 16KB size restrictions, the actual URL or header allowed depends heavily on the characters in the
URL or headers. If a URL or header contains only standard ASCII characters, a 16KB size limit equates to
16384 characters. However, if a URL or header contains characters other than standard ASCII characters,
converting from byte size to character length becomes a bit murkier.
Because
http.sys processes URLs as UTF-8 by default, and UTF-8 characters consume between 1 and 3
bytes in memory, an allowable URL length could be anywhere from roughly 5461 characters to 16384
characters. A general rule of thumb when using non-ASCII characters though is to assume 2 bytes per
character if there is extensive use of Unicode characters, which equates to a maximum URL length
(including query string variables) of 8192 characters.
4
Chapter 1
04_596985 ch01.qxp 12/14/05 7:46 PM Page 4