IIS suddenly serving garbled UTF-8 - asp.net

I was working on a website. All files are UTF-8 encoded without BOM. Everything was working fine. Suddenly my IIS or ASP.NET started serving the files with all umlauts garbled.
file contents of .aspx file on webserver
öäü
returned to browser by IIS
öäü
I can "fix" this problem by re-saving the files as UTF-8 with BOM but I don't want to do that. The HTTP Response header claims the content is UTF-8
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
but it is not. If I create an identical file and change it's extension from .aspx to .html, it gets served correctly.
This isn't restricted to a single website running on IIS but it's happening on ALL websites running on the IIS server. It not some setting in the web.config, it's happening even when I completely delete the web.config.
What could have caused this and why is this happening?
EDIT
OK so turns out I had to add <globalization fileEncoding="utf-8" /> to the web.config after all, i.e.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<globalization fileEncoding="utf-8" />
</system.web>
</configuration>
fixed it. It's strange because I'm pretty sure I didn't have that setting in my web.config before.

Yeah, as you said. DotNet Globalization feature page is responsible for configuring DotNet Framework globalization settings, such as language, culture, encoding options.
We can change globalization settings for ASP.NET applications at the Web server level when we want to apply to all ASP.NET applications on the server.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831368(v=ws.11)
You could post your solution as an answer to help the guy that runs into the same issue.

Related

SSRS report drop down boxes and calendar controls are not populating after configuring X-Content-Type-Options: nosniff response header in IIS

Recently we have added X-Content-Type-Options: nosniff header to IIS as a part of security fixes. then we started facing issue with SSRS reports are rending properly in IE11. we debugged with F12 options and identified the server is blocking SSRS report default java scripts. And the MIME types in report is text/javascript which is blocking by IIS.
If we remove these headers in IIS then report is working fine. So, is there any solution to make application works with keeping headers?
I ran into this a little while back with the embedded report viewer in our web site. The way we got around it was to remove the header for that page. To do this you need a config.web file in the directory of the report viewer page that has the following in it:
<location path="ViewReport.aspx">
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Content-Type-Options" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
Hope this helps.
Shawn

IIS and Static content?

According to Ultra-Fast ASP.NET: Chapter 3 - Caching:
Files that the browser retrieves from the server should be stored in
the browser’s cache as long as possible to help minimize server
round-trips.
But how does IIS know what a static content actually is and is not?
Is it just images, CSS, JS and not ASPX, ashx...?
Where can I see in IIS what is already considered to be static and what is not ?
What about the scenario where a page has been declared with <%# OutputCache header (without location)? Are the images, CSS and JS source files inside of it also being output cached with the same properties?
As a best practice, I should set one year into the future as the maximum expiration time. I should use that as the default for all static content on the site
So I did this :
But later, after pressing OK, I can't find any summary menu which shows me: to whom I already put a response header (in this case: the css folder).
Currently, in order to see that css folder has been applied with response headers - I have to go to the css folder again --> Http Response Header-->Set Common Headers --> and then I see it. It isn't written in the web.config.
But if I do it for a file (Login.aspx for example): I do see it in web.config:
<configuration>
<location path="Login.aspx">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseExpires" cacheControlMaxAge="1.00:00:00" httpExpires="Fri, 15 Feb 2013 00:00:00 GMT" />
</staticContent>
</system.webServer>
</location>
</configuration>
I understand your situation. Sometime its confusing how IIS handles a file. Its also different for IIS 6 vs IIS 7 and different for Classic App Pools and Integrated mode app pools. My experience is mostly with Integrated App Pools on IIS 7.5, so thats the environment I can comment on most accurately.
First Question
But how does IIS knows what is actually a static content and what is
not?
Is it just images , css , js and not ASPX , ashx...?
Where can I see in the IIS what is already considered to be static and
what not ?
You can inspect the list of file handlers in IIS by navigating to your website and then click 'Handler Mappings'. By default these are inherited from the .Net base web.config which is in a different location depending on your .Net framework version.
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
If a file being requested isn't already explicitly mapped to another handler it falls to a catch all handler (*) as the last option (System.Web.DefaultHttpHandler) which determines if it is a static file or a directory browsing request. So Static files are simply files not bound to another handler already. For example you'll see that *.aspx is already mapped to System.Web.UI.PageHandlerFactory prior to this default handler. So its going to be processed by that handler and not be considered a static file. If you removed that mapping you could technically serve *.aspx as a static file if you really wanted to (just for proof of how it works).
But you can also explicitly list a file type as a static file by adding an entry in your web.config's httpHandlers section mapping the file extensions to System.Web.StaticFileHandler in IIS. For example:
<configuration>
<system.webServer>
<handlers>
<add name="StaticHandler" verb="*" path="*.zip" type="System.Web.StaticFileHandler" preCondition="integratedMode" />
</handlers>
</system.webServer>
</configuration>
This example is using the <system.webServer> config section, so its for an App Pool running in Integrated Mode.
Second Question
What about the scenario where a page has been declared with <%#
OutputCache header(without location) . does the images,css,js src
files inside of it , are also being output cached with the same
properties?
No. Because the page is being server as a separate request (maybe even by a separate handler) it can have totally different cache headers/hints. The host page and the resources it may use are not related from a caching perspective.
In fact you may even want to have a shorter cache period for *.html and a longer cache period for *.jpg or *.png? Something to consider.
Third Question
As a best prcatice , I should set one year into the future as the
maximum expiration time.I should use that as the default for all
static content on the site
Hmm... I might not go as far as one year. How about one month? I would set a global policy like this:
<configuration>
<system.webServer>
<staticContent>
<!-- Set expire headers to 30 days for static content-->
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
</system.webServer>
</configuration>
This is the same as the sample you showed above, but is not inside a <location> element, instead it is right in the root <configuration> element so it is the default policy. Again this is for an App Pool running in Integrated Mode. Sometimes you also need to turn on:
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<!-- stuff -->
</modules>
</system.webServer>
<system.webServer>
This just makes sure that static files are processed through the managed static file handler which respects the above configuration elements.
Edit to Address Comments
The documentation for the configuration dialog you posted above is located here: Configure the HTTP Expires Response Header (IIS 7)
Apparently these settings are saved in C:\Windows\System32\inetsrv\config\applicationHost.config
I do not have IIS7 and personally develop on IIS 7.5 now. So please post a comment if you can verify this location is accurate!
The static content is the one that IIS is read and send to the browser with out any processing. There you can setup IIS to include some Cache-Control Header to cache it on clients browser computers.
You can do that ether by direct setup IIS, ether by commands on web.config as you say. The commands that you add on web.config and concern the IIS, did not have to do with asp.net it self, but the IIS, and IIS saves his configuration on a different file, so when you change that cache control headers direct on IIS you do not see them on web.config.
Now for the static content like images, CSS, JavaScript, and other similar files they say that you can follow the "never expire" policy by adding 10 years expire.
The issue here is that if you can not change the content of the static file, if for example you cache a javascript file with 10 years, and you make a small change on it, then you need ether to change the file name, ether to add some parameter at the end of it.
Now the <%# OutputCache on a control is referred to the server cache and not to the client, and what is actually do is to cache the render of the control on the server so the next time you ask it to not lose time to renders it again but read it from cache - is still send it to the browser.
And you can also read this answer for some more: What are difference between IIS (Dynamic and Static) cache,OutPutCache and browser cache

asp.net - post file gives 404 page result even though posted file is well under maxRequestLength

I have a page on my ASP.NET site which uploads files.
I have attempted to tweak the web.config file to allow for larger uploads.
In my web.config, I set:
<httpRuntime maxRequestLength="2097152" executionTimeout="3600" />
On my page, when I attempt to upload smaller files, no issue...even at 25MB.
However, when I attempt to upload a 50MB file, I still get a 404 error page.
NOTE: I have a flash control on a different page which can upload almost 2gb with no issues, using this same web.config setting.
Same result on different PCs, same result when posted to different web servers.
My web server is Windows Server 2008 R2.
Any ideas of the cause? Why would flash be ok, but plain jane upload control have this problem?
I found the answer. Windows Server 2008 R2 is using IIS7 (of course), and in IIS7, you have to set the following in your web.config file (in my example to increase the limit to 2gb):
<system.webserver>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
</requestFiltering>
</security>
<system.webserver>
This worked, when everything else didn't. IIS7 by default limits uploads to 30mb unless this override is set.
The executionTimeout applies only if the debug attribute in the compilation element is False. (see also http://msdn.microsoft.com/en-us/library/e1f13641.aspx)
So try it when starting your application in Release config.

Firefox 4.0 always refreshes the Silverlight XAP File

I've trouble with the new FireFox 4.0 Release.
In my Website i hosted a Silverlight Object, named Visualisation.
In Firefox 3.6, Chrome, IE 7, 8, 9 the Browsers load the XAP File Once and get it from cache if not then do a postback or re-enter the site.
In FF 4 it reloads XAP File everytime i enter the site.
I tried a lot and searched the web but have no idea to fix the problem.
My Silverlight Object has the:
<param name="enableCacheVisualization" value="true"/>
The Site which hosted the Object has the Page Head
<%# OutputCache Duration="600000" VaryByParam="none" %>
and i have an own web.config in the ClientBin folder:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<location path="Visualisation.xap">
<system.webServer>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="10.00:00:00" />
</staticContent>
</system.webServer>
</location>
</configuration>
Any Ideas?
The site runs on a IIS7 (Win 2008 Server) with .Net 4.0 and c# as Backcode
hope for hints
I'd use firebug under the net tab to see what cache headers are being sent by your web server. You want to see something like: Cache-Control: max-age=31536000 and maybe an Etag.
There is a setting for caching under HTTP Headers in IIS under the common headers menu I think.
Another thing you might try playing with is the MIME type. It should be "Content-Type: application/x-silverlight-app"
If the headers are getting sent correctly and Firefox is choosing to ignore them, then there might not be anything you can do.
I've actually had the opposite problem with Chrome. Chrome seems to be very agressive with it's caches and I find myself running old versions of .xaps.
It seems firefox 4.0+ caches only files with 5MB or less in size.
See bug report

JSON webservice response compression in IIS 7

I have trouble with JSON response compression. I look to response headers after uploading website to production server (Windows 2008, IIS 7) and found uncompressed response. Turning on "Enabled static compression" and ""Enable dynamic compression" in IIS control panel does not effect. ASPX pages was responsed gzipped, but webservice response uncompressed.
I looked to google, but no answer found about this trouble. Also, I try this json ihttpmodule compression way (and adding to web.config this module) - but this source is excellent working at development machine with ASP.NET development server (and have seven times response size reduced) and totally ignored at IIS7.
How I can apply gzip compression to json responses from my webservice? Thanks.
PS .NET 3.5
I stumbled across the same problem with JsonCompressionModule. It was working on the development server but not on IIS 7. I figured out that under IIS 7 it isn't enough to add the handle under system.web but also under system.webServer (see below). After this change it works fine on IIS 7.
<system.web>
<httpModules>
<add name="JsonCompressionModule" type="JsonCompressionModule"/>
</httpModules>
</system.web>
<system.webServer>
<modules>
<add name="JsonCompressionModule" preCondition="managedHandler" type="JsonCompressionModule"/>
</modules>
</system.webServer>
IIS dynamic compression uses the response content type header to determine if it should compress the content or not. The default settings do not compress "application/json". You can find more information at http://www.iis.net/configreference/system.webserver/httpcompression
To add it, open an admin command prompt, run the commands below then restart the IIS service.
cd \Windows\System32\inetsrv
appcmd.exe set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json',enabled='True']" /commit:apphost
You may want to add a few other content types. The only application/* types the default dynamic settings compress is application/x-javascript.
Please try and examine what are the request headers which the client sends. Accept-Encoding should have gzip or deflate value.
Make sure though that the client is able to decompress JSON.
There is a solution which is able to set Accept-Encoding and perform GZIP compression all together—Helicon Ape (http://www.helicontech.com/ape/). The following configuration will do both the tricks:
# Manually set required request header
RequestHeader append Accept-Encoding gzip early
# Enable high-level (9) comression for JSON files
SetEnvIf mime application/json gzip=9

Resources