We have an Azure web app with AI configured.
The module from AI is added like this:
<modules >
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" />
</modules>
We want the precondition, because we don't want static files to be captured but when using the precondition, https traffic never gets captured, while http traffic does.
Any ideas how to use the precondition="managed" but making sure https traffic is also captured by AI?
For one or the other reason, adding the httpmodule for classic mode solved my problem.
Anyone who can explain this?
Related
I've been developing a RESTful API using Web Api 2 and as part of it I implemented batch requests using JSON objects as described in one of their wiki articles (https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching).
This process went smoothly enough while testing using IIS Express, but when I deployed the application in IIS 8 under an IIS application the batch requests no longer function properly. Every sub request returns 404 not found even when the url points to the proper location. However, this only happens when the program is deployed as an application under an IIS website. If you simply drop the program into the root of an IIS website batching behaves correctly.
I have some images of the failure / success responses in Fiddler, but SO won't let me post them. So as an example, a batch POST request made to the IIS website hosted at "http:// domain.com/api/v1.0/" with the inner url set to "realtimedata/queues?queueIds=1" works fine, but when the app is accessible at "http:// domain.com/test/api/v1.0/" the same request with the same inner url returns 404, even though "http:// domain.com/test/api/v1.0/realtimedata/queues?queueIds=1" is a perfectly valid address that can be called fine without using the batch request. (The space in between "http" and "domain in the example urls is just to get around SO's link limit, so imagine they aren't there). Does anyone know what is going on?
After more testing, I found that this was an issue particular to hosting via OWIN in IIS. I had to register my routes against the GlobalConfiguration.Configuration object instead of a new’d up Configuration object and then the 404’s were resolved. I’m not sure why this was the case, but it worked.
Add/modify system.webServer section in your web.config according to this sample:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Please note, that path="/*" replaced with path="*." in add tag.
I would like to enable SSI on an Azure Web Site to but using .html rather than .shtml. SSI is enabled but for the life of me I can't find a way to get it to process .html.
Locally I've added a handler to web.config
<system.webServer>
<handlers accessPolicy="Read, Script">
<add name="ASPClassicHtml" path="*.html" verb="GET,HEAD,POST" modules="IsapiModule" scriptProcessor="%IIS_BIN%\asp.dll" resourceType="File" />
</handlers>
</system.webServer>
And that works fine, but when I upload to the azure web site my i get the following error;
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Any suggestions?
It's not possible at the moment but SSI module inclusion on WAWS is apparently in the pipe-line.
http://social.msdn.microsoft.com/Forums/en-US/windowsazurewebsitespreview/thread/391a7918-00e8-49af-b2db-675980aebbd0
We have a problem occuring on some of our developer workstations: when visiting a URL without a filename (e.g. http://localhost/), IIS 7 returns a 404 error. Everyone is running Windows 7/IIS 7.5 and ASP.NET 4.0. The application pool is configured to use Classic pipeline mode.
Default documents are enabled, and default.aspx is in the default document list.
I enabled failed request tracing, and see this in the log:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit",
NewHandlerModules="IsapiModule",
NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Later on, I see that this IsapiModule is rejecting the request:
ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="404",
HttpReason="Not Found", HttpSubStatus="0",
ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo=""
It looks like IIS thinks the ExtensionlessUrl-ISAPI-4.0-64bit should be handling the request. When I look at that module's configuration, it shows that it should be matching path *., so I'm confused why it is matching no path.
A Google search turns up this post on the IIS.net forums from 2005. Unfortunately, no solutions are offered, just an acknowledgement of the problem.
When I update my app pool to use integrated mode, the problem goes away. Unfortunately, it has to run in Classic mode.
What can I do to get IIS to server our default documents again?
It looks like Microsoft released an update that enables the ExtensionlessURL HTTP handler to work with extensionless URLs. Unfortunately, this breaks certain other handlers. In my case, the DefaultDocument handler under classic app pools. The solution is to remove the ExtensionlessURL handlers in our application's web.config:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrl-Integrated-4.0" />
</handlers>
</system.webServer>
I solved the problem with putting the "StaticFile" handler in HandlerMapping in front of "ExtensionlessUrlHandler-*"
I noticed when removing the managed .NET framework (4.0) from the application pool, it fixed the problem for me too!
We don't use .NET at all in our IIS environment!
I use the following rule in web.config URL Redirect as workaround to solve this:
<system.webServer>
<rewrite>
<rules>
<rule name="Default document rewrite" stopProcessing="true">
<match url="^(.+/)?$" />
<action type="Redirect" url="https://{HTTP_HOST}/default.aspx" />
</rule>
</rules>
</rewrite>
</system.webServer>
Changing the StaticFile order helped to fix the issue, when setting default document to a web site application in IIS, while the root website also had another default document.
Adding the DefaultDocument component to IIS in add/remove windows features and then inserting the name of my default script ( index.php) worked for me.
I am trying to set up a website under IIS 7.5 with multiple tcp.net bindings.
Since the service is behind a loadbalancer I need multiple endpoints for the service:
log.o1881.no/log/service.svc
log.core1.o1881.no/log/service.svc
this works for the http bindings when I configure in web.config:
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
The following error message appears when the following tcp.net bindings are added to the site:
808:log.o1881.no
808:log.core1.o1881.no
Server Error in '/Log' Application.
This collection already contains an address with scheme net.tcp. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item
I also tried to add this to web.config:
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<baseAddressPrefixFilters>
<add prefix="net.tcp://log.o1881.no:808/log" />
<add prefix="net.tcp://log.core1.o1881.no:808/log" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
This does however not work.
Since the service will be deployed on multiple servers, I would very much like to be able to make this work through configuration and IIS setup, not in code.
Is this possible to do, or is there another way to handle this scenario (multiple binding names on http and net.tcp, due to loadbalancing)?
According to the documentation the use of multipleSiteBindingsEnabled tells WCF to ignore any <baseAddressPrefixFilters>.
"Any baseAddressPrefixFilters settings are ignored, for both HTTP and non-HTTP protocols, when multiple site bindings are enabled using this setting."
So this configuration contradicts itself, you are specifying address prefixes and simultaneously instructing WCF to ignore them since you are have multipleSiteBindingsEnabled specified.
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<baseAddressPrefixFilters>
<add prefix="net.tcp://log.o1881.no:808/log" />
<add prefix="net.tcp://log.core1.o1881.no:808/log" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
I think the multipleSiteBindingsEnabled is best for scenarios where you are only interested in using HTTP schemes.
Otherwise don't use it and you can in fact have multiple tcp.net bindings on different ports in the same IIS Site/App hierarchy.
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="net.tcp://log.o1881.no:808/log" />
<add prefix="net.tcp://log.core1.o1881.no:808/log" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
Hope this helps others :)
For as far as I've found, this is impossible:
Supporting Multiple IIS Site Bindings
Endpoint Addresses
How can WCF support multiple IIS Binding specified per site ?
If anyone finds a solution for this, please share...
When used at site level, the IIS7 URL Rewrite 2 module saves its configuration in the web.config file of that site. I'm using Sitecore CMS, and best practice is to store any web.config customisations in a separate config file for ease of upgrading, staging/production setups etc.
Is there any way to specify a different config file for IIS7 redirects?
I know that application-level rewrites are stored in ApplicationHost.config, but I have several sites running on the server and would like to keep them separated.
Thanks, Adam
In order to support this best practice you've mentioned, Sitecore implements pluggable configs, but only for the elements inside <sitecore> section of web.config. So, unless IIS7 URL rewrite provides some way to move its stuff to a separate config (like ASP.NET does for connectionstrings.config), I'm afraid you'll have to keep it in the main web.config file.
Sorry if I'm saying obvious things.
You can also try to use rewrite maps
<rewrite>
<rewriteMaps configSource="rewriteMaps.config" />
</rewrite>
Sample rewriteMaps.config file:
<rewriteMaps>
<rewriteMap name="CustomRewrites" defaultValue="">
<add key="/instructions" value="/documents" />
</rewriteMap>
</rewriteMaps>
I'm not familiar with the url rewriting config, but I have an example of moving the url mapping to a separate file:
<urlMappings configSource="config\urlMappings.config"></urlMappings>
And that file looks like the following:
<?xml version="1.0"?>
<urlMappings enabled="true">
<add url="~/somedealer" mappedUrl="/?theme=4" />
<add url="~/someotherclient" mappedUrl="/?theme=12" />
</urlMappings>
I'm sure the url rewriting works the same way.