ISA Server error 12217

A client was having an intermittant error on websites he is hosting on one of his servers. The error was occurring only on some pages and only some of the time. The error message displayed was “The request was rejected by the HTTP filter. Contact your ISA Server administrator. (12217)”. He asked me to have a look.

I tried a couple of pages on the sites and sure enough the error was occurring intermittantly. I put the error message into Google Groups and the only hit with an answer was in German!

I put the resolution into Altavista’s Babelfish translation service and discovered that I had to:
Click on Firewall Policy
->Right-click on the website publishing rule
->Select Configure HTTP
->On the General tab ->de-select Block high bit characters
->Click Apply

Having done this, the sites worked with no errors – ISA Server 2004 blocks characters like √�, √� and √� by default and the only way to stop pages with these characters being blocked is to use this fix.

12 thoughts on “ISA Server error 12217”

  1. I’ve come across a similar thing with the filter Microsoft offer for IIS. I suspect the original intention was to block attacks based on overlong UTF-8 encodings (I say a bit about this issue at and the Unicode Standard itself has information on it). However, it’s relatively easy to get secure UTF-8 parsing right – and to know you have it right.

    There are also phishing opportunities with Internationalised URIs, but only a small subset of these would be prevented by this blocking (though if you let people create their own sections on your site then someone with control of could have customers phished from where the letter before “hisBit” is actually a Cyrillic letter Te, not the Latin letter “Tee”).

    Another reason for blocking is that we’ve only relatively recently had a standard on how to deal with characters in the range U+0080 and higher in URIs (although it’s been clear for some time that the standard would use UTF-8 encoding escaped as per the existing URI character escape rules), and there is still some variation in practice and hence scope for difficulties. The ISA Server people may just have considered it best to block those who didn’t know what they were doing and force them to stick to the US-ASCII range.

  2. Thank you for this… I was running into an error with our client database, which had a lot of French names with ô’s and various other accented characters.

    A quick Google search turned up your blog. Problem solved in under 1 minute.


  3. Hi Tom,

    I am getting this error on an ASP.NET web site I have hosted in the DMZ behind my ISA Server 2004 Firewall. I have enabled high bit characters on the HTTP filter as you mentioned above but still seem to get the error (on pages where a carriage return character is likely to be appearing.
    Is there any other configuration settings I should be looking for (sorry, but I am a bit of an ISA novice)

  4. Stuart,

    I’m afraid I’m a bit of an ISA Server novice as well – sorry I can’t answer this one for you – if you figured it out, you might leave a comment here so others will find it…



  5. I am facing problem regarding .. i am running isa 2004

    on workstations dosent display full graphics

    what should i do ?

  6. yes tom i am confirm.. however i tried to uninstall isa 2004 but it dosent by saying ( failed to unregister vpn ) .. after that it start creating diffrent kinds of problem. so then i again install win 2003 and isa 2004…

    my problem is solved but i again facing problem .. my application event log always gets full with these events

    [The daily summary for day “03/08/2006” was not created. Use the source location 1001.470.4.0.2161.50 to report the failure.]

    plz guide me .. also tell me the best way to uninstall.


  7. I tried it in my isa server, but I can’t edit http protocol under general tab. the “filtering” option isn’t available for clicking. Any ideas???? isa server is 2004 sp1.

  8. Just ran into the exact problem listed for one of our newly published internal pages. Googled, found your page, fixed problem, partied like a rock star. Thanks!

  9. Hey Stuart,

    I am sure you are long past your carriage return problem. However, I have an answer for the next guy that sees your post. After talking to microsoft, they state they intentionally break urls with an encoded CRLF (%0d%0a) to prevent cross site scripting. A work around is to use HTTP authentication (we were using forms auth). We ended up changing our code to use a POST instead of a GET.

Comments are closed.