Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 707
  • Last Modified:

Difference in IIS5 and IIS6 in handling Japanese characters in HTTP request header

I am trying to make the same HTTP request to an IIS5 and IIS6 web servers. My request contains a set of HTTP header which have the values in Japanese characters. I have these characters encoded in Shift_JIS.

While the same request gets successfully served by the IIS5 web server with a 200 OK response, the IIS6 web server gives a 400 bad request.

Can someone help on what could be the possible reason for this? Do I need to make any configuration changes in the IIS6 setup so as to enable it to serve the request as well?

Please help!

Thanks.
0
swapan_gupta
Asked:
swapan_gupta
  • 5
  • 4
1 Solution
 
OBonioCommented:
What type of page are you requesting and has that been enabled in IIS6?  IIS6 is very much locked down by default and won't serve up ASPX or classic ASP pages unless it's configured to.
0
 
swapan_guptaAuthor Commented:
It is a very basic html page. In fact, it does not even use the HTTP header with the Japanese value.
But I still need to send an HTTP header that contains a Japanese character.
0
 
OBonioCommented:
Hmm.  I can't find any reference to IIS 6 throwing errors for what I assume are UTF headers.

So it's the request going to the server that contains the header, and IIS is just rejecting it out of hand?  Have you checked the application log on the server?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
swapan_guptaAuthor Commented:
Yes, IIS6 is just rejecting the request. The IIS Web server logs just say that it was Bad Request.
Is there a way we can enable IIS 6 to dump  the complete HTTP request that it received in its logs?

Below is the format of the request:

GET /divya/page1.html HTTP/1.1
Host: ashish.ad.abc.com
Keep-Alive: 300
Connection: keep-alive, TE
TE: trailers
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
TEST1: ßLŒ_½ßE"û)'user1
SESSION_ID: C9lzOMaiMnr/9jBch0Kl/MpK3JG8ilXpVb8felv0zwnGMKsvnWCXX78+/tvtySnoa4+ut2O2kCo+p+PcLxo82yQ6+unwucq/nqLZZTqO3WIfYJS+jqTxCbOVg/DKt7vfu4gRj7IQaNNUcNtC13/xytcuCrajwb4Zq/UMTTtovlOy5Vnwr3m0T+gvAb6d9F1TCocKStlsyXnB0lMWfncmfpcOklQZW54BUcki5zE2AgojqB7wtq5k/lKlcRg+lrAEOIlq6JLfytKkb2qL0HD2R4bppxuxhgQQCUW5mkkB/OCLCbloCbPsdZwdOLUeXyiLPgMDuVJOVr6rbd0GmCqr5yd6XP1XaFZ1A08x4P6XTJz6czIl322vXwvINpfFkM78d4Qs6m8KJfs6YkqINyDYwS6WOkqw1Eee2HY78oBr3T/RYHxOD3GciXtyj1NPUS3t+3+4ZNq/eQMcN85FI9RjuHHqit6EF4olYR+NXG6/G5Uvvxkk8qGPPfyxThysVDOf
TEST_USER: ßLŒ_½ßE"û)'user1
accept-language: en-us,en;q=0.5
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-encoding: gzip,deflate
accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
UID: ßLŒ_½ßE"û)'user1
0
 
swapan_guptaAuthor Commented:
Kindly note that the Japanese characters have not been correctly represented in this Post once I submitted my comment.
Basically, what is showing up as ßL__½ßE"û)' in this Post are actually Japanese characters in the HTTP Request headers.
0
 
OBonioCommented:
What about the Application log in the Windows event log?
0
 
OBonioCommented:
This may be worth investigating :

http://msdn.microsoft.com/en-us/library/aa364675(VS.85).aspx

In particular the AllowWeakHeaderValueSyntax value.
0
 
swapan_guptaAuthor Commented:
Yes, this was helpful.

Setting this value to 1 made IIS 6 HTTP parser to be more liberal when parsing the header value. Now IIS 6 does not give a 400 Bad Request and instead serves the resource. Also, I could see the header value correctly getting printed by an ASP hosted on the IIS 6 web server.

Am wondering how much of a security impact will this change in the registry value have? Perhaps IIS 5 parser was already allowing such header values (considering that these might be legal values in the context of a localized value), but IIS 6 is more restrictive in nature.

Now the question is how should this actually be accomplished with IIS6, when there can legal localized characters in the header value?
Is it recommended to reduce the restrictive nature of the IIS 6 HTTPparser as was done in this case so that IIS6 serves the valid requests?
0
 
OBonioCommented:
Looking at the HTTP RFCs a little closer, it's possible to specify a Content-Type header in the request and within that specify a charset :

Content-Type: application/json; charset=utf-8


0

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now