Ok, so... famous saying... this works locally, but not when I deploy.
I recently switched to using Less.js so that I could dynamically change my less variables with Javascript. Again, locally this works like a champ.
In my header I have it referenced:
<link rel="stylesheet/less" type="text/css" href="~/Content/main.less" />
<script src="//cdnjs.cloudflare.com/ajax/libs/less.js/3.9.0/less.min.js"></script>
When I use Visual Studio to deploy this to my Azure App Service I get a 404 on the less file and it all breaks.
I FTP'd into my server and the file is indeed there. https://i.imgur.com/cV5FQOW.png
I double checked to make sure that my properties for the less file are right. I have the build action set to Content and Copy if Newer. https://i.imgur.com/I3DbfHg.png
No matter what I do, if I go looking for that main.less file the azure server returns a 404.
As an FYI, the site is a ASP.Net MVC 5 website. I am using bundling, but only for external css like JQueryUI. I have removed the bundling of my CSS to work with the new stuff.
What am I missing?
Ok! After a bunch of attempts and searches I finally found a related error and found my solution.
This poor gentleman was having an issue serving up JSON files (angular2 app, http request for file json file, 404 on azure) and that made me think I had the same problem.
Eureka! I needed to update my web.config to let it serve LESS files.
<system.webServer>
<staticContent>
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
<system.webServer>
Hope this helps someone else who runs into the same issue.
I'm fairly new to IIS so apologies if this is a basic question.
I have an IIS config serving an internal company website (php instead of asp.net). The prod version of the website is at the 'Default Web Site' level and I've got demo and test versions of the website mapped as virtual directories. The demo and test version are essentially copies of the prod directory. I've noticed the with the web.config copied to these VDs, I get an error 500 on the root url for the VD only. I.E. main website is https://mainwebsite.com and works fine but https://mainwebsite.com/demo/ doesn't work while https://mainwebsite.com/demo/index.php works fine.
The web.config file is pretty basic:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
</handlers>
<defaultDocument>
<files>
<add value="index.php" />
</files>
</defaultDocument>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="00:03:00" />
</staticContent>
</system.webServer>
</configuration>
Moving the web.config file out of the way in the VD resolves the issue. Even though the files are identical, I wouldn't think that the file should cause a conflict as my understanding is that IIS supports multiple web config files.
Although I have a workaround in place by renaming or deleting the file, I am wondering if there's a way to keep the file in place without it causing this error.
Thanks to Panama Jack in the comments, I was able to resolve my issue.
I got this response with detailed errors:
Error Summary
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
And further down:
Config Error
Cannot add duplicate collection entry of type 'add' with unique key attribute 'value' set to 'index.php'
To resolve, I simply commented out this line in the web.config XML:
<add value="index.php" />
I'm sure there's a better way to approach this but for now, this gets me my answer and also how to get more info from IIS when the logs are not useful.
if you create a virtual directory to another web root
web.config will cause this (personally I think the location of this file is totally insane.. mixed with htm and images etc. )
Replicate the directory somewhere else without the web.config file/excluding it..then point the virtual directory there.. & have a task set up to copy newer files over..
I am trying below
RegisterLink(new LinkEntry { Rel = "import", Href = Url.Content("~/Themes/SomeTheme/components/font-roboto/roboto.html") });
in my orchid layout, for using polymer. however this request is throwing a 404(on network tab in chrome.).
I am very much new to Orchid cms and hence struggling with this. Any help on this.
Note: I found that I have a class ResourceManager which implements IResourceManager. I am not sure if this is where I need to do make some changes. So adding this note as well.
Thanks
You need to place a web.config inside Themes/SomeTheme/components folder (same as ThemeMachine/Styles) making one modification:
<handlers accessPolicy="Script,Read">
<add name="StaticFileHandler" path="*" verb="*" modules="StaticFileModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
</handlers>
Remove (if existing) all web.config files in children folders.
You really need a web server to host polymer assets unless you disable web security. It can be any web server server. In addition, the ~ directive probably wouldn't be recognized by chrome file loader.
I have Microsoft.Owin.FileServer (v2.1.0) set up in my Owin pipeline, and setting up FileServerOptions with EnableDirectoryBrowsing = true works great for showing the directory contents in both my console host and iisexpress.
It's when I try to view a particular file (so, the StaticFiles part) I have problems in iisexpress. Still works great in the console host, but in iisexpress I get a 404:
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Most likely causes:
- The directory or file specified does not exist on the Web server.
- The URL contains a typographical error.
- A custom filter or module, such as URLScan, restricts access to the file.
I do have the latest Microsoft.Owin.Host.SystemWeb referenced in the web host.
Adding <modules runAllManagedModulesForAllRequests="true"> didn't work for me (VS2013, IIS Express).
Forcing all requests to use the Owin pipeline did:
(in web.config)
<configuration>
<system.webServer>
<handlers>
<add name="Owin" verb="" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
</handlers>
</system.webServer>
</configuration>
I had to add the following setting:
<modules runAllManagedModulesForAllRequests="true">
to get the module that Microsoft.Owin.Host.SystemWeb automatically registers to run for routes like *.txt, *.js that IIS was assuming were static files to run through the Owin pipeline.
This setting does have performance implications for actual static files, but this works for me.
I've just struggled with this for the last couple of hours, adding the handler below did work however I don't believe this was the correct approach, it caused public void Configuration(IAppBuilder appBuilder) to be invoked twice.
<add name="Owin" verb="" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
I did some reading and found https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline
which then lead me to use UseStageMarked().
So now my call to UseStaticFiles() is followed by a called to UseStageMarker() like so:
appBuilder.UseStaticFiles();
//allows owin middlwares to be executed earlier on in the pipeline.
appBuilder.UseStageMarker(PipelineStage.Authenticate);
There is a very good read on it here:
You can find UseStageMarker inside the Microsoft.Owin package here: https://www.nuget.org/packages/Microsoft.Owin/
I hope this helps someone else.
Thanks
Steve
I use WebClient type to upload *.cab files to my server. On the server side, I registered a HTTP handler for *.cab file with the PUT method as below:
<add name="ResultHandler" path="*.cab" verb="PUT" type="FileUploadApplication.ResultHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
But I always get a "405 method not allowed" error. The response said the allowed methods are as below:
Headers = {Allow: GET, HEAD, OPTIONS, TRACE
Content-Length: 1293
Content-Type: text/html
Date: Fri, 27 May 2011 02:08:18 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET}
Even if I explicitly allow the PUT method in the IIS Request Filtering for my web application, the same error still occurs.
I suspect this is a IIS related issue. I'm hoping someone could shed some light on this for me.
Often this error is caused by the WebDAV module that try to handle this kind of requests. An easy solution is to remove it from modules and from handlers of the system.webServer section just inside your web.config file.
Here a configuration example:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
I enabled the Failed Request Tracing, and got the following info:
<EventData>
<Data Name="ContextId">{00000000-0000-0000-0F00-0080000000FA}</Data>
<Data Name="ModuleName">WebDAVModule</Data>
<Data Name="Notification">16</Data>
<Data Name="HttpStatus">405</Data>
<Data Name="HttpReason">Method Not Allowed</Data>
<Data Name="HttpSubStatus">0</Data>
<Data Name="ErrorCode">0</Data>
<Data Name="ConfigExceptionInfo"></Data>
</EventData>
So, I uninstalled the WebDAVModule from my IIS, everything is fine now~
The IIS tracing feature is very helpful.
I tried most of the answers and unfortunately, none of them worked in completion.
Here is what worked for me. There are 3 things to do to the site you want PUT for (select the site) :
Open WebDav Authoring Rules and then select Disable WebDAV option present on the right bar.
Select Modules, find the WebDAV Module and remove it.
Select HandlerMapping, find the WebDAVHandler and remove it.
Restart IIS.
Taken from here and it worked for me:
Go to IIS Manager.
Click on your app.
Go to "Handler Mappings".
In the feature list, double click on "WebDAV".
Click on "Request Restrictions".
In the tab "Verbs" select "All verbs" .
Press OK.
I had this problem with WebDAV when hosting a MVC4 WebApi Project. I got around it by adding this line to the web.config:
<handlers>
<remove name="WebDAV" />
<add name="WebDAV" path="*" verb="*" modules="WebDAVModule"
resourceType="Unspecified" requireAccess="None" />
</handlers>
As explained here: http://evolutionarydeveloper.blogspot.co.uk/2012/07/method-not-allowed-405-on-iis7-website.html
Best to just remove the unused WebDAV feature. Go to Programs and Features => Turn Windows Features On or Off and disable WebDAV Publishing under
Internet Information Services => World Wide Web Services => Common HTTP Features
Removing the WebDAV-module should be sufficient. Just change your Web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule" />
Here is what worked for me:
Open up IIS and click on your Site.
Double Click on the Modules
Right Click on WebDavPublishing and remove.
Restart running WebSite.
I was using Angular 8 and was .NET core API.
I add the following in my service web.config file. That resolve my error.
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I had the same problem, with a RESTful API running on aspnet core.
I didn't want to uninstall the WebDAV, and I tried most of the remedies described above. I tried to set the verbs="*" both on the site and on the server itself, but without success.
What did the trick for me was the following:
IIS Manager -> Sites -> MySite -> HandlerMappings -> aspNetCore -> Edit
-> Request Restrictions -> Access -> None (it was Script).
After that everything worked, even if I replaced the original WebDAV options.
Another important module that needs reconfiguring before PUT and DELETE will work is the options verb
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="OPTIONSVerbHandler" />
<remove name="WebDAV" />
<add name="OPTIONSVerbHandler" path="*" verb="*" modules="ProtocolSupportModule" resourceType="Unspecified" requireAccess="Script" />
</handlers>
Also see this post: https://stackoverflow.com/a/22018750/9376681
For whatever reason, marking WebDAVModule as "remove" in my web.config wasn't enough to fix the problem in my case.
I've found another approach that did solve the problem. If you're in the same boat, try this:
In the IIS Manager, select the application that needs to support PUT.
In the Features View, find WebDAV Authoring Rules. Double-click it, or select Open Feature from the context menu (right-click).
In the Actions pane, find and click on WebDAV Settings....
In the WebDAV Settings, find Request Filtering Behavior, and under that, find Allow Verb Filtering. Set Allow Verb Filtering to False.
In the Actions pane, click Apply.
This prevents WebDAV from rejecting verbs that it doesn't support, thus allowing a PUT to flow through to your RESTful handler unmolested.
Another tip from me. I have used PHP + IIS, and the Handler Mappings for PHP did not have the PUT verb.
Go to IIS Manager->Your site->Handler Mappings->PHPxx_via_FastCGI->Request Restrictions->Verbs, then add PUT.
That's it!
I had the same issues with PUT, PATCH and DELETE but didn't have anything with WebDav installed. Resolution 1 in this article finally helped me: http://support.microsoft.com/kb/942051
for asp.net core 5
IIS-> Sites -> MySite -> HandlerMappings -> aspNetCore -> Request Restrictions -> Access -> None (it was Script).
For me this error wouldn't go away and allow PUT methods, whatever i did.. uninstalled webdav, put configuration in web.config to remove webdav from handlers and modules, and set up PUT as an allowed verb on the request filters on iis.. and ensure iis handler mappings handling the request had PUT configured..
My problem was eventually due to bad installation of ASP.NET 4.5 Extensions. Removed everything related to asp.net from server roles and features. restarted. readded the roles and restarted. everything worked with above config.
--- The below will make PUT be accepted, but will send it to the wrong handler. --ignore the below
finally, adding PUT verb as allowed verb on TRACE handler mapping on iis worked.. since i had enabled failed error tracing, and this verb was not allowing the verb.
last time i had the same problem on another server's IIS, it was due to a missing '/' at the end of the URL since it was using a default handler without using the default document probably and now i realize that.. so check IIS handler mappings if nothing else helps.
I had this problem but nothing related to WebDAV was the issue. In my case, the client was sending a POST to www.myServer.com/api/chart. This call should be handled by the "ExtensionlessUrlHanlder-Integrated-4.0", however, somehow a local file structure was created in my server directory "...\Server\api\chart\". This meant that the "StaticFile" handler was being called instead. Deleting those local files finally solved the problem.
For Windows server 2012 -> Go to Server manager -> Remove Roles and Features -> Server Roles -> Web Server (IIS) -> Web Server -> Common HTTP Features -> Uncheck WebDAV Publishing and remove it -> Restart server.
I have a same problem for PUT and DELETE request in IIS10 for asp.net core 5.
I just added below lines in web.config and problem is resolve.
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
You can do solve by other way from IIS also.
In IIS, select the application
Add rules to allow HTTP verbs in Request Filtering (But this alone doesn't work).
Go to "Modules", then select the "WebDAV Publishing" module and remove it.
Go to "Handler Mappings", then select the "WebDAV" and remove it.
in cmd run IISRESET
This is my solution, alhamdulillah it worked.
Open Notepad as Administrator.
Open this file %windir%\system32\inetsrv\config\applicationhost.config
Press Ctrl-F to find word "handlers accessPolicy"
Add word "DELETE" after word "GET,HEAD,POST".
The sentence will become <add name="PHP_via_FastCGI" path="*.php" verb="GET,HEAD,POST,DELETE"
The word "PHP_via_FastCGI" can have alternate word such as "PHP_via_FastCGI1" or "PHP_via_FastCGI2".
Save file.
Reference: https://learn.microsoft.com/en-US/troubleshoot/iis/http-error-405-website
If you are only developing on your machine, using IIS to run your application and you are not going to use WebDAV then just go to Control Panel > Add or Remove Windows features and disable WebDAV
If IIS app pool is running under classic mode, make sure you have the following in your web.config
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" modules="IsapiModule" scriptProcessor="c:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" />
In my case I had relocated Web Deploy to another port, which was also the IIS port (not 80). I didn't realize at first, but even though there were no errors running both under the same port, seems Web Deploy was most likely responding first instead of IIS for some reason, causing this error. I just moved my IIS binding to another port and all is well. ;)
To prevent WebDav from getting enabled at all, remove the following entry from the ApplicationHost.config:
<add name="WebDAVModule" />
The entry is located in the modules section.
Exact location of the config:
C:\Windows\System32\inetsrv\config\applicationHost.config
In case anyone still using ASP classic needs to solve the method not allowed trouble for ASP, you also need to re-register the ASP classic handler for telling it to handle additional verbs. By default, it only handles GET, HEAD and POST.
<system.webServer>
<!-- other stuff ... -->
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ASPClassic" />
<add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST,PUT,DELETE,PATCH" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="File" />
</handlers>
</system.webServer>
In order to remove WebDAV module and handler using appcmd you can use this:
appcmd uninstall module WebDAVModule
appcmd clear config -section:system.webServer/handlers -"[name='WebDAV']"
This can also be use in a release pipeline if needed.