I'm trying out running a customer application on Azure Web sites, to see what problems we might be running into. This application uses a number of custom HttpHandlers and web.config handler mappings to these handlers. Unfortunately all of the custom handler requests fail with:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
The handlers are configured in web.config in and they work fine on local dev, but I can't get them to work on Azure.
It looks more like a permissions problem, like it's looking for a file on disk, but there's no File restriction mode specified:
<add name=".wc_wconnect-module" path="*.wc" verb="*"
type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule"
preCondition="integratedMode,managedHandler" />
Are custom handler mappings supported, or am I just seeing some limitation in terms of file extensions that are not supported? If the latter how can I work around any URL filtering that might be causing this?
Related
I'm trying to determine the cause of a 500 server error I'm seeing in the diagnostics logs for my AspNetCore 2.1.5 app that's running in an Azure App Service instance:
HTTP Error 500.53 - URL Rewrite Module Error.
Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").
Symptoms include:
Incomplete HTML responses (A 200 status code is returned, but occasionally only a portion of the content is displayed - refreshing the page 1-3 times usually fixes this)
Frequently slow response times ~10-40 sec - it's as if the app isn't warmed up.
Possibly Relevant Information:
Application insights doesn't show any of these failures or slow response times anywhere.
I'm not explicitly using any rewrite rules in my config.
Calling/Not Calling app.UseResponseCompression() in startup doesn't make a difference
Calling/Not Calling app.UseHttpsRedirection() in startup doesn't make a difference
Enabling/Disabling "Https Only" in the azure portal doesn't make a difference
I'm not seeing any problems locally
Scaling between B1,B2,S1,S2 app service plans doesn't make a difference
Turning off https only and using non-ssl endpoints doesn't make a difference
Here's my WebHostBuilder call:
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.SetBasePath(Directory.GetCurrentDirectory());
})
.UseSerilog()
.UseStartup<Startup>()
.UseApplicationInsights();
The only similar results I find when Googling for this are 500.52 errors, but they're always related to incorrect url rewrite rules which I'm not (explicity) using.
For others benefit, I recently hit on the same issue, after 2 hours deep diving into Azure portal, there seems a known issue with application insight with APPINSIGHTS_JAVASCRIPT_ENABLED setting enabled combined with <urlCompression ...> settings, you can find more details from the link below
https://github.com/Microsoft/ApplicationInsights-Home/issues/282
Two possible solutions
1. Turn off APPINSIGHTS_JAVASCRIPT_ENABLED
Set APPINSIGHTS_JAVASCRIPT_ENABLED to false either from your web.config appSetting or Azure App blade applicaiton setting
2. Turn off dynamicCompressionBeforeCache
Search in the web.config and Find <urlCompression ..> node, disable both static and dynamic compression
<urlCompression doStaticCompression="false" doDynamicCompression="false" />.
If you have CDN like cloudflare configured, you should consider to remove urlCompression completely.
I'm trying to use jquery dataTables with a few extras on Azure Websites. It generates a sizeable query string (2121 characters in testing). This returns a bad code on Azure websites (The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.).
To get it working locally I edited the web.config with this:
<httpRuntime maxQueryStringLength="4000" maxUrlLength="4000"/>
(I believe only the maxQueryStringLength is really needed).
Anyway, all is fine locally and on another server but on WA Web Sites I can't get it working. Any ideas?
Try customizing IIS Request Filtering parameters.
I suspect you're using Cassini (Visual Studio development server) to develop locally.
Limitations related to Query String and/or URL max lengths occur at two levels on Azure Websites (or any IIS environments) :
ASP.NET Runtime : These limits are lifted using the httpRuntime node and its associated attributes
IIS Requests Filtering module : IIS also applies its own filtering rules regarding URL and Query String length, even before the request is processed by the ASP.NET Runtime. By default, the maximum allowed length for a query string is 2048 (see here). You should set the appropriate values in your Web.config, under the requestLimits subnodes, eg :
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="4096"/>
</requestFiltering>
</security>
</system.webServer>
See also this question
I have a ServiceStack project with ServiceStack Razor added. Any time I try and navigate to the root of the site, I'm getting redirected to /metadata.
This does not happen on my dev machine, only in my hosted environment (AppHarbor).
I do have a Default.cshtml in the root of my project.
Navigating to other URLs work fine: /default1.cshtml, /myservicewithviews
I've tried messing with the DefaultRedirectPath in my AppHost, but that didn't help.
Trying to force it DefaultRedirectPath = "default.cshtml" result in a redirect loop. Which makes sense.
What is causing this?
AppHarbor only publishes files marked "Content" when building projects (AppHb FAQ). This file was the only one not marked content and why I was only experiencing this in my hosted environment and could access all other content.
Not detecting a default document causes ServiceStack to set a RedirectHttpHandler to /metadata - shown around here
Another noteworthy point is that AppHarbor's load-balancer causes their internal port numbers to show up in ServiceStack URLs when performing things like Response Redirects.
To fix this problem, you add the following to your Web.Config:
<appSettings>
<!-- AppHarbor Setting to stop AppHb load balancer internal port numbers from showing up in URLs-->
<add key="aspnet:UseHostHeaderForRequestUrl" value="true" />
</appSettings>
You could also configure this setting in your AppHarbor config panel.
How to enable the error information in the Sharepoint site by modifying the web.config file.?. I have done the following changes in web.config file
Callstack = true
CustomErrors mode = Off
Compilation debug = true
But still i am not able to get the call stack details(error details) in the sharepoint site for a error, instead of that i am getting this following error
"To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" file located in the root directory of the current web application". Please correct me on this?.
custom errors mode off, (or on, I can never remember). Then set debug=true. The catch is that there are many different web.configs used by sharepoint. There's one on the web application level (in inetpub, virtual directories), then there's one for layouts pages, control templates, etc in /web server extensions/14/. You have to make these changes in all of the relevant web configs associated with your code.
And obviously, make sure this is always turned off in production for security reasons.
You do not need to do an iisreset, changing a web.config file will cause one automatically.
Did you run iisreset?
Make sure you're changes in the web.config look like these:
<customErrors mode=”Off” />
<SafeMode … CallStack=”true” … >
<trace enabled=”true” pageOutput=”true”/>
PS: Showing stack traces in a production environment is not recomenned, instead use a tool like ULSViewer for diving through the log files.
Have some strange behaviour regarding output caching in an ASP.NET 4 application on IIS 7.5. I've been able to repeat the problem simply on other empty setups, I'm certain this is a bug, but unsure how to report it to Microsoft.
A site in IIS responds to more than 1 domain, the .NET application examins the hostname, and produces content accordingly. For example, it may print the name of the request URL in a blank page. Eg, www.first-domain.com, and www.second-domain.com
The web.config has the appropriate caching, urlCompression, and httpCompression all turned OFF under the system.webServer node.
The aspx page sets the cache-control header for public, with either a future date for expires, or a max-age value.
Visiting www.first-domain.com outputs the page that successfully writes 'www.first-domain.com'.
However, visiting www.second-domain.com outputs a page that writes 'www.first-domain.com'.
Examining the failed-request-traces, System.Web.Caching.OutputCacheModule has found the cached output (even though the .config files have turned the function off), the cache has matched even though the request URL hostname are different, and thus the second request will output the results of the first request to the different domain for as long as the max-age/expiry was set for, before the correct page for the second-domain will appear.
Either setting cache-control to private, or removing the 'OutputCache' module in the web.config solves the problem, while maintaining the correct cache-control headers sent to the browser, but obviously, I can't take advantage of kernel caching when I need it.
I can't find any MSDN documentation on how the OutputCacheModule is configured.
Has anyone else experienced this issue, how can I go about enabling kernel caching and let it take into account URL Hostname (without separating the application to different sites in IIS).
Thanks.
Update:
Adding SetSlidingExpiration has no effect, as the kernal cache still caches the output regardless of the request hostname. The only scenario now is to either disable output caching, or run a duplicate instance of the app on each domain it will run - considering the drop in server performance this would result in vs. the increase of performance gained in using output caching, we decided to disable output caching for this app.
No answer has been provided after 9 months, and no solution has been found, only a workaround, perhaps this will be fixed in the next version of IIS greater than 7.5...
--
Adding SetSlidingExpiration has no effect, as the kernal cache still caches the output regardless of the request hostname. The only scenario now is to either disable output caching, or run a duplicate instance of the app on each domain it will run - considering the drop in server performance this would result in vs. the increase of performance gained in using output caching, we decided to disable output caching for this app.
I was having a very similar problem and no solutions here helped me.
TLDR: Forcefully removing the OutputCache module on the Web.config was the only solution I found.
My scenario was a little bit different.
I have CORS set up in Application_BeginRequest, answering Access-Control-Allow-Origin for specific hosts that call me (setting it to * has not been reliable).
My Controller also sets Cache-control: public for it's responses.
What I found
Whenever I set Cache-control: public, IIS forcefully caches the response. Breakpoints on either Application_BeginRequest or my Controller were never hit a second time.
Disabling output and kernel caching via IIS Manager as seen below would have me hitting the Application_BeginRequest breakpoints, but never got me into the Controller. Something was still caching responses.
This article suggested removing the OutputCache module from IIS would help.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="OutputCache" />
</modules>
</system.webServer>
Doing so allowed me to hit my Controller, finally.
What would help even more
If someone from MS or not could shine a light whether there is a way to change this behavior. OutputCache could be useful in some parts of an application and unnecessary in others.
Beware
Maybe I'm(we're?) solving the wrong problem here.
Maybe IIS was taking over caching in this scenario because it should. Maybe proxies along the way between my server and the user would behave just like that in that exact scenario, and if that's the case then working around this on IIS is wrong. I'll have to figure that out and maybe you should too.
I have similar problem. I use custom url rewriter. I have pages example.com/articles and example.com/art-ANY_ID.html. Both url map to articles.aspx (in second example as articles.aspx?id=ANY_ID). It worked fine with ASP.NET 2.0 and Classic pipeline mode. After we have changed it to ASP.NET 4 and integrated mode, we have got strange behaviour: both url return identically output. It was any page like example.com/art-ANY_ID.html.
Now we removed <add extension=".html" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" /> from section <caching enabled="true" enableKernelCache="true"> and it fine works. I not understand why http.sys cache it.
Have you find any explanations?