I have just started using Orchard 1.9. I come up with a big issue which I have never encountered when I used Orchard 1.8.x.
The new version gives out gibberish code after the site is deployed to a remote server. It works fine on local server.
I am sure it's not an encoding issue, because after I switch the encoding to UTF-8, it creates a different set of gibberish.
How to solve this problem?
I have a theory that there is something strange going on with Output Cache combined with content encoding on your deployment server resulting in content perhaps being encoded twice?
With Output Cache turned back on try adding this line in your root web.config right before </system.webServer>
<urlCompression doDynamicCompression="false" doStaticCompression="true" />
</system.webServer>
Does that help anything?
Edit:
You can try enabling dynamic compression and adding dynamicCompressionBeforeCache attribute with false, it's a default value but hosting may have changed it in their configs.
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" />
Related
I am facing an issue where I am getting a 413 Request Entity Too Large whenever I post/put JSON to our servers running IIS 7.5 through a Citrix NetScaler.
We have tried to set the aspnet:MaxJsonDeserializerMembers to 30000, 40000 and 512000, as so:
<appSettings>
<add key="aspnet:MaxJsonDeserializerMembers" value="xxx" />
</appSettings>
as well as setting the <jsonSerialization maxJsonLength="xxx"/>
But without any resolution.
Setting the aspnet:MaxJsonDeserializerMembers in our local test environment, where we don't have a Citrix NetScaler, works just fine .
Is there any settings in the NetScaler that I should know of? or Is there some IIS settings I have to be aware of as well, considering that this works in our local test environments I am leaning towards the later, but I wan't all basis covert.
Edit: After further investigation, it surely seems that the NetScaler is the source as we can post to the API from behind the NetScaler.
As it turns out, it was actually a combination between the two products.
Internally we use SSL and Client Certificates which means we needed to configure a IIS property called "uploadReadAheadSize"
http://forums.asp.net/t/1702122.aspx?cannot+find+uploadReadAheadSize+in+applicationHost+config+in+IIS7+5
This is done in the host config or though the IIS manager.
...
<system.webServer>
<serverRuntime uploadReadAheadSize="{BYTES}" />
</system.webServer>
...
We used 10 MB = 10485760 Bytes for now which shows to be enough. Since this is defaulted to 48KB you may reach this rather fast.
I've installed the ImageResizer libraries in my DotNetNuke environment as described at http://imageresizing.net/docs/workswith/dotnetnuke
But I'm getting redirected to the root of my portal as soon as I call the resizer extension
My resize settings in the web.config look exactly the same as the example in the installation guide
<resizer>
<pipeline fakeExtensions=".ashx" />
<plugins>
<add name="MvcRoutingShim" />
<add name="DiskCache" />
</plugins>
</resizer>
Looks good to me, but as soon as i try to call an image through the extension, I get redirected to the root of the site.
Call to:
http://localhost/Portal/0/Image.jpg.ashx
Redirects to:
http://localhost/
I can't figure out how to fix this. Is it a DotNetNuke or a IIS setting?
Things I already tried:
Checked the Configuration of the site and made sure the .ashx extension has the "Verify that file exists" checkbox unchecked.
Tried using an other extension
Tried adding a wildcard in IIS
checked resizer.debug.ashx,
2 Issues detected:
(Warning): To potentially see additional errors here, perform an image resize request.
Server(Warning): Microsoft-IIS/6.0 does not support Integrated mode or does not have it enabled.
You must append the .ashx extension to any image requests you wish to process.
It seems the handler is never called and the redirect takes place based on the fact that there's no physical file called Image.jpg.ashx.
Any ideas how to fix this?
It was a defective rewriterule in SiteUrls.config causing this problem:
<RewriterRule>
<LookFor>[^?]*/(\d+)/(.*)</LookFor>
<SendTo>~/Default.aspx?tabid=$1</SendTo>
</RewriterRule>
I have a cabinet which consists of several servers, handling quite a bit of traffic.
I need to construct a system to keep statistics - and I struggle to find out if it's possible or makes sense to make a null-request to a server? That is, calling something like http://XXX.XXX.XXX.XXX?objectid=9563828&sreq=2854&nc=29291947829 and letting IIS do nothing with it, except adding the request in the log.
As mentioned, my servers handle a lot of traffic - and every bit of CPU-power and byte I can save, counts in the long run = save money.
At the moment, my plan is to make IIS return nothing on 404-errors, but I'm not sure if this is the best approach. And are all requests logged (having caching in mind)?
Theories or suggestions, please?
Solved - it is possible by adding
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
in the configuration file. The reason I didn't succeed, is that this command is apparently only supported from IIS 7.0 and later and I was testing it on a version 6.5
TLDR
I have an IHttpHandler that performs compression. It works fine on its own. But then I added an IHttpModule that performs a completely unrelated task on those (and all other) responses, and now IIS is re-compressing the already-compressed responses. How can I prevent this?
The Whole Story
I have an IHttpHandler implementation that performs combination and compression (among other things) for CSS and JS files. Everything in the IHttpHandler works exactly like I want it to.
But then I added an IHttpModule implementation that removes unnecessary response headers (Server, X-AspNet-Version, etc.) from all responses (including the dynamic responses that are generated by the IHttpHandler) during the PreSendRequestHeaders event.
However, it seems that simply registering an IHttpModule, regardless of what it actually does, causes IIS to apply compression to the response, even if the response is already compressed.
So, my IHttpHandler explicitly compresses the response and sets the Content-Encoding header, then (if and only if) the IHttpModule is also registered, IIS re-compresses the response (so there's a doubly-compressed response that browsers can't read).
I don't want to disable all default compression. I still want HTML from views to be compressed (and I want any CSS and JS that doesn't go through the IHttpHandler to also be default-compressed).
I'm guessing there's no easy solution to my problem because it seems like a bug in IIS. IIS should not compress a response that is already compressed.
I tried adding the following to my web.config, but it had no effect:
<httpCompression>
<dynamicTypes>
<add mimeType="text/css" enabled="false" />
<add mimeType="application/javascript" enabled="false" />
</dynamicTypes>
</httpCompression>
(From my interpretation of the documentation, that should disable compression for dynamically generated CSS and JS.)
I also tried this, to no effect:
<httpCompression>
<dynamicTypes>
<clear/>
</dynamicTypes>
<staticTypes>
<clear/>
</staticTypes>
</httpCompression>
(From my interpretation of the documentation, that should disable all default compression.)
Update
In my IHttpHandler, I call context.Response.Flush at the very end. If I remove this call, the response doesn't get double-compressed. I'm fine with this as a solution. Can anyone explain why this is happening?
Update 2
My best guess is that calling Flush puts the response into such a state that IIS doesn't think the response is already compressed (and so it applies default compression). Even though in my module I can check both...
that Response.Headers contains a Content-Encoding header and
that Response.Filter is non-null and is one of the System.IO.Compression types.
Not sure why IIS can't determine that the response is already compressed from those facts.
I have a text file that I am trying to browse to using the browser http://files.mydomain.com/test.txt and I get a:
HTTP Error 404.0 - Not found
I double checked and the text file does exist. When I add a test.htm file, I have no issues.
Can someone help? Something tells me it's security issue.
Have you checked the following:
Your DNS 'A' record for 'files' is pointing to the correct IP address
If your server is using a shared IP address across multiple sites have you configured a HTTP host header?
Is there a mime type set for the .txt extension?
Have you made any changes to the Handler Mappings for the site? e.g. mapped the .htm extension to say the ASP ISAPI filter and accidentally removed the StaticFile handler?
Can you serve other static content such as .jpg, .gif, .pdf etc?
Kev has covered most of the possible problems, but for reference there is another possibility.
Confirm that in Request Filtering you either
have .txt as an Allowed extension, or
have Allow unlisted file name extensions ticked in Edit Request Filtering Settings
The same effect can be achieved with the following web.config section:
<system.webServer>
<security>
<requestFiltering>
<fileExtensions>
<add fileExtension=".txt" allowed="true" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
Also make sure also that the website is started. I was getting 404 and then realized that the Default Website was stopped because another website (Sharepoint) was using port 80. Sometimes the obvious is what gets you.
Add the MIME-Typ by going to ...
features / Mime-type
right click,
add,
put in the file extension ".txt"
and the mime-type "text/plain"
ok
et voila
I know this is an old post, but this might still help somebody out. I ran into this problem with my Asp.Net Core application. In my case it turned out that static files are served from a subdirectory called 'wwwroot' by default. Creating that subdirectory and moving the file in their solved it for me:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/index?view=aspnetcore-2.2&tabs=windows#web-root