1

I have a very long URL on a site hosted on Windows 2003 x64 that looks like this:

http://myhost/a_very_very_long_url_around_300_chars_long

(i.e. a single, very long segment around 300 chars long)

Problem is, I'm getting a 400 Bad Request response from HTTP.SYS (it doesn't even reach IIS). I can tell because these requests show up in system32\LogFiles\HTTPERR, e.g:

2009-09-17 19:51:29 200.123.179.9 3636 192.168.129.50 80 HTTP/1.1 GET /a_very_very_long_url_around_300_chars_long 400 - URL -

I tried setting UrlSegmentMaxLength in the registry and this fixes the issue on my Windows 2003 x86 box but not on the x64 production server. I tried this on another Win2k3 x64 server and it also failed.

Any hints?

5
  • Is your "a_very_very_long_url_around_300_chars_long" an actual physical file or are you using some sort of re-writing tool? Sep 25, 2009 at 18:05
  • Yup, I'm using rewriting with IIRF, there's no actual file. However, the since the request is blocked by http.sys it never reaches the IIRF or IIS... Sep 28, 2009 at 2:47
  • So, you've got a referrence to a URL that's longer than HTTP.Sys likes. Understandable that HTTP.sys blocks this. It's interesting that this works on x86 and not x64. I'd say at this point you need to open a case with Microsoft. Sep 29, 2009 at 13:41
  • BTW - You did reboot or do the IISReset /STOP | Net Stop HTTP | Net Start HTTP | IISReset /Start process, right? Reg changes for HTTP.sys require a reset of the HTTP service, not just IISReset. Sep 29, 2009 at 16:33
  • Yes, I even rebooted the box... Sep 29, 2009 at 20:50

3 Answers 3

1

Since you are seeing errors in the HTTPERR log, this is not a URLScan issue - HTTP.sys has not handed the URL off to IIS, so the URLScan ISAPI filter won't run.

From a different Windows IT Pro article, HTTP.sys has taken over for URLScan for most issues regarding URL and segment lenghts, and you are correct in examining the HTTP.sys registry keys.

Interestingly enough, I'm able to change this, but have problems making physical directories or virtual directories that are this long due to MAX_PATH issues and Metabase restrictions.

If you are using a rewriting tool, you actually might be having issues that are apparent in only the x64 implimentation, or a slight difference between how x86 and x64 interprets the URL.

1

Ultimately I migrated to Windows 2008 R2 (IIS 7.5) x64 and applied the UrlSegmentMaxLength change, and it worked. So I'm guessing this was a bug in Windows 2003 x64...

0

First make sure you are using the latest version of URLscan (found here)

Then make sure that the following entries are in urlscan.ini, if you need to increase them (to over 300 for MaxUrl) this is the place to do so:

; There are 3 special case limits:
;
; - MaxAllowedContentLength specifies the maximum allowed
; numeric value of the Content-Length request header. For
; example, setting this to 1000 would cause any request
; with a content length that exceeds 1000 to be rejected.
; The default is 30000000.
;
; - MaxUrl specifies the maximum length of the request URL,
; not including the query string. The default is 260 (which
; is equivalent to MAX_PATH).
;
; - MaxQueryString specifies the maximum length of the query
; string. The default is 2048

MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .