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
Related
I am using shibboleth SP 3 and IIS 8 on one server. I protect a folder "secure" and redirects to a test ADFS, where I configured the extraction of the UPN from the AD.
My attribute-map.xml looks like this:
<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Attribute name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" id="UPN" />
</Attributes>
Everything works fine. I check the http headers and server variables, all the custom shibboleth headers are there and corresponding server variables with the prefix HTTP_
I am deploying this on a test server, Windows Server 2012 with IIS 8. My problem is, I still have the server variables, but without the HTTP_ prefix, and I don't have the HTTP headers any longer, while my app relies on them.
The configuration files are almost identical. I have dug in the Shibboleth SP wiki, which is a murder to read, I don't find where I can finetune how the attributes are added in HTTP headers or server variables.
Do you have any clue?
thanks.
Shibboleth SP 3 uses the new iis7_shib.dll instead of the old isapi_shib.dll and it no longer populates the headers by default. See https://wiki.shibboleth.net/confluence/display/SP3/IIS#IIS-NewVersioninV3oftheSP.
However, you can edit the <ISAPI> element to useHeaders... see: https://wiki.shibboleth.net/confluence/display/SP3/ISAPI for documentation, but it should be as simple as replacing
<ISAPI>
with
<ISAPI useHeaders="true">
within your shibboleth2.xml file.
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'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?
I am trying to figure out how to use url rewrite and Application Request Routing (ARR) to rewrite across different app pools on the same server.
In a simplified version, here is what I have: a REST service API is implemented with 2 virtual directories, Service.A and B, so virtual directory is part of url to access to access resources A and B
GET [https://]api.mycompany.com/Service.A/A
GET [https://]api.mycompany.com/Service.B/B
What I want to achieve is to have one single external url for the api without virtual directory names, and obviously not having to go through a code refactoring (to merge solution files and builds)
GET [https://]api.mycompany.com/A
GET [https://]api.mycompany.com/B
I implemented a url rewrite rule to match /A in path and replace with /Service.A/A, with some code like this in web.config at the default web site level, which works fine.
<rewrite>
<rule name="AddServicePrefix" enabled="true">
<match url="^A[/]?.*" />
<action type="Rewrite" url="/Service.A/{R:0}" />
</rule>
</rewrite>
The problem is that when I assign a different application pool to Service.A (from the app pool of default web site), this will fail immediately with a 403 error, but this is a requirement on our side to have applications/virtual directories running under different app pools to minimize impact when any pool fails or recycles.
I have done some research. This previous post below basically said "if you want to re-route request to another app-pool, you have to make a hop, whether that hop is over winsock or named pipe or whatever else" without much details. I also went through ARR guide but couldn't figure out exactly how to use ARR for this case.
http://forums.iis.net/t/1151510.aspx?Rewrite+across+application+pools+
Any help? Suggestions and comments whether I am in the right direction?
Thanks!
oh, forget to mention the environment: currently in dev environment, IIS 7.5 on Windows 7, Url Rewrite 2.0, and ARR 3.0, installed by Web Platform Installer.
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.