In our enviroment, we have an english ISA2006(SP1) on a Win 2003 R2 SP2 Server (english) for publishing different Sharepoint portals from our customers. - Once a WSS 3.0 farm - Once a MOSS-farm both with formbased authentication. WSS over SSL, MOSS at the moment without SSL.
Everything is working fine, but if we want to upload a document in folders, which contains german umlaut's like ä,ö,ü in the name, we always get an error Code 500 (12202). In the ISA log: 12232 The server denied the specified Uniform Resource Locator (URL). Contact the server administrator
This error happens only with Microsoft IE (different versions tested). With a Mozilla Browser it's working without any errors. If we change the authentication to basic, the upload also working with Microsoft IE. We also have checked the HTTP Security Filter: the normalization and block extended characters are unchecked.
hi ferrix thanks for your fast answer. I have already made some further investigations. During the upload process, I can see one "get" and a few later one "post" request on the ISA Server log. The IE has changed the url for the later "post" request. And will access this url as anonymous.
Good first step, now you know one part of the problem. Next you need to find out if this URL is broken right away in the browser's request or is being changed by ISA and broken there.
My guess is that it is a problem in Internet Explorer, because of this from Wikipedia:
There exists a non-standard encoding for Unicode characters: %uxxxx, where xxxx is a Unicode value represented as four hexadecimal digits. This behavior is not specified by any RFC and has been rejected by the W3C. The third edition of ECMA-262 still includes an escape(string) function that uses this syntax, but also an encodeURI(uri) function that converts to UTF-8 and percent-encodes each octet.
As you have found, the difference between good and bad URLs is this non-standard unicode escaping. I am not a sharepoint expert, but maybe there is a jscript that is using this way in IE, and ISA is denying it because it's non-standard.
In my opinion, first you should see if there's any Microsoft supported solution, since all the involved steps are using MS products! But then, my mind always goes toward a coding solution: it would be easy to re-encode these URLs with an IsaScript filter.