Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
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? –  Christopher_G_Lewis Sep 25 '09 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... –  Mauricio Scheffer Sep 28 '09 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. –  Christopher_G_Lewis Sep 29 '09 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. –  Christopher_G_Lewis Sep 29 '09 at 16:33
    
Yes, I even rebooted the box... –  Mauricio Scheffer Sep 29 '09 at 20:50
add comment

3 Answers

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.

share|improve this answer
add comment
up vote 1 down vote accepted

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...

share|improve this answer
add comment

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

share|improve this answer
1  
I thought URLScan was practically obsolete with IIS 6 windowsitpro.com/article/articleid/39979/… –  Mauricio Scheffer Sep 23 '09 at 2:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.