Windows protocol installer won't run from a browser - ithit-webdav-server

We have IT Hit WebDAV Server and IT Hit WebDAV Ajax Library running in a Windows development environment. All is working well except when a user tries to run the protocol installer from the webpage popup message. The popup says “Select OK to download the protocol installer”. When I click okay, it opens a new tab with a 404 error. I can see in the URL that it is looking in the correct folder, and the msi file IS in that folder.
I tried it in 3 different browsers with the same results. I also tried running the WebDavServer wizard project and get the same results. The only way I’ve found to get it to run from a browser is through the AjaxFileBrowser app. In there, the popup message is different and it works when you click the link for the Windows version.
Do you have any ideas for why it’s not running from the browser?

Here are some suggestions:
The MIME-map is not configured. By default IIS has a mapping for .msi and .gz extensions, but maybe it is deleted from IIS for some reason. Here is how to set MIME mapping in web.config:
<staticContent>
<mimeMap fileExtension=".pkg" mimeType="application/octet-stream" />
<mimeMap fileExtension=".deb" mimeType="application/octet-stream" />
<mimeMap fileExtension=".msi" mimeType="application/octet-stream" />
<mimeMap fileExtension=".gz" mimeType="application/x-gzip" />
</staticContent>
Your WebDAV Ajax Library files are located under the WebDAV path. Your server engine is processing all requests in your code so they do not reach the file system. Just move your static files to some other folder, outside of WebDAV. In case of IT Hit WebDAV samples, the static files are typically located in /AjaxFileBrowser/ folder.

Related

"no enabled plugin supports this MIME type" message on mobile device for PDF document

Recently the google search console reported a coverage issue on our ASP.NET website for the urls pointing to PDF documents.
So far in our web.config file we don't have any MIME setting for PDF documents. But indeed, both on localhost and in production, in Chrome, in mobile context PDF url generate empty content with the message no enabled plugin supports this MIME type:
In Desktop context the PDF document is opened directly in Chrome.
Updating the web.config file with that (below) leads to the same described behavior, both in mobile and desktop contexts.
<system.webServer>
<staticContent>
<remove fileExtension=".pdf" />
<mimeMap fileExtension=".pdf" mimeType="application/pdf" />
</staticContent>
<system.webServer>
Updating the web.config file with that (below) forces the browser to download the PDF in both contexts.
<system.webServer>
<staticContent>
<remove fileExtension=".pdf" />
<mimeMap fileExtension=".pdf" mimeType="application/octet-stream" />
</staticContent>
<system.webServer>
So far this is the best solution since it allows mobile users to get the PDF and this will fix the google warning.
However I'd like to open the PDF in the browser itself in desktop context and download it in mobile context. Is it possible?
The observed behavior is device/media-type specific; handling this at the web server level is challenging to put it mildly. There are some simple approaches but they take you only so far, some commercial IIS detection solutions can help.
I guess, making adjustments to the website would be probably more beneficial. There might be header issues, or acknowledging this behavior and manage the expectations.
Consistent behavior across mobile devices is difficult and there is simply no foolproof way to determine whether a device, mobile OS, or form factor is able to open in HTML-embedded PDF documents like it is the case on the desktop. The lowest common denominator of displaying an embedded document on all common browsers and devices is usually having a download link.
For me the issue was viewing the page in responsive mode, Chrome doesn't support showing pdf in this mode, switched to regular desktop mode and the PDF appeared. The mobile view can be tested by switching back to responsive mode after the file has been loaded.
I had the same error message for a relative PDF link at localhost, but the same url worked as expected when deployed to a live https url

How to remove error about glyphicons-halflings-regular.woff2 not found

ASP.NET MVC4 Bootstrap 3 application is running from Microsoft Visual Studio Express 2013 for Web IDE.
Chrome console shows always error
http://localhost:52216/admin/fonts/glyphicons-halflings-regular.woff2
Failed to load resource: the server responded with a status of 404 (Not Found)
This file exists in the fonts directory in the Solution Explorer. Build action is set to "Content" and Copy to Output directory is "Do not copy like in other font files".
Bootstrap 3 is added to the solution using NuGet.
How to fix this so that this error does not occur?
Application shows Glyphicon and FontAwesome icons properly. This error always occurs at application startup.
This problem happens because IIS does not know about woff and
woff2 file mime types.
Solution 1:
Add these lines in your web.config project:
<system.webServer>
...
</modules>
<staticContent>
<remove fileExtension=".woff" />
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
</staticContent>
Solution 2:
On IIS project page:
Step 1: Go to your project IIS home page and double click on MIME Types button:
Step 2: Click on Add button from Actions menu:
Step 3: In the middle of the screen appears a window and in this window you need to add the two lines from solution 1:
In my case, I've just downloaded the missing file directly from here: https://gitlab.com/mailman/mailman-website/raw/a97d6b4c5b29594004e3855f1ab1222449d0c211/content/fonts/glyphicons-halflings-regular.woff2
Add this one to your html if you only have access to the html:
<link href="//netdna.bootstrapcdn.com/bootstrap/3.0.0/css/bootstrap-glyphicons.css" rel="stylesheet">
For me, the problem was twofold: First, the version of IIS I was dealing with didn't know about the .woff2 MIME type, only about .woff. I fixed that using IIS Manager at the server level, not at the web app level, so the setting wouldn't get overridden with each new app deployment. (Under IIS Manager, I went to MIME types, and added the missing .woff2, then updated .woff.)
Second, and more importantly, I was bundling bootstrap.css along with some other files as "~/bundles/css/site". Meanwhile, my font files were in "~/fonts". bootstrap.css looks for the glyphicon fonts in "../fonts", which translated to "~/bundles/fonts" -- wrong path.
In other words, my bundle path was one directory too deep. I renamed it to "~/bundles/siteCss", and updated all the references to it that I found in my project. Now bootstrap looked in "~/fonts" for the glyphicon files, which worked. Problem solved.
Before I fixed the second problem above, none of the glyphicon font files were loading. The symptom was that all instances of glyphicon glyphs in the project just showed an empty box. However, this symptom only occurred in the deployed versions of the web app, not on my dev machine. I'm still not sure why that was the case.
I tried all the suggestions above, but my actual issue was that my application was looking for the /font folder and its contents (.woff etc) in app/fonts, but my /fonts folder was on the same level as /app. I moved /fonts under /app, and it works fine now. I hope this helps someone else roaming the web for an answer.
This problem happens because IIS does not find the actual location of woff2 file mime types. Set URL of font-face properly, also keep font-family as glyphicons-halflings-regular in your CSS file as shown below.
#font-face {
font-family: 'glyphicons-halflings-regular';
src: url('../../../fonts/glyphicons-halflings-regular.woff2') format('woff2');}

MVC Site Compression not working

I have done and checked the following.
1. made sure components are installed...
Made sure everything is enabled for the server in IIS
Made sure the site has modules enabled
Enabled the settings in web.config
<system.webServer>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>
My site here http://tinyurl.com/lv44hl4 according to few sites when i enter my url in it says not compressed, for example
http://tinyurl.com/nzfv9z4 (GZIP TEST SITE WITH MY URL)
Am i missing something? (using IIS8, mvc5 and .net 4.5.1)
Ctrl-Shift-I will open developer tools in Google Chrome. According to that your content is compressed via gzip.

Publishing an MVC4 App on IIS 7.5 but Having Permission Issues

I published an intranet on IIS 7.5. If I try to go to the website, I get "403 - Forbidden: Access is denied - You do not have permission to view this directory or page using the credentials that you supplied".
If I right click on the application folder on IIS Manager and go to Manage Application and then Browse, I get "HTTP Error 403.14 - Forbidden - The Web server is configured to not list the contents of this directory". It then proceeds to tell me that A default document is not configured etc. etc. I do have a default document listed in the web.config file as follows:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
<modules runAllManagedModulesForAllRequests="true" />
<defaultDocument>
<files>
<add value="Index.cshtml" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
What am I doing wrong? Many thanks.
check the folders permissions: right click on the folder, click on properties go to Security and add the appropriate user (like IUSR_...). hope it helps.
It turned out I was publishing the app completely the wrong way. I was going by how previous ASP.Net apps created as Websites and not Solutions were published. This MVC app needed to be placed in inetpub/wwwroot folder in the server. If I published through Visual Studio I think this would have happened anyway. I didn't have VS in the server. So I placed the files manually there (just copied from my local inetpub/wwwroot since I successfully published there earlier). The last thing I needed to do was go to IIS Manager and converting the project folder into an Application. Now cooking on gas.

How to deploy a website to a local IIS

I'm trying to deploy a website to my local IIS for the first time
I added a new website to my local IIS (also created a directory for it)
I published it with File System method from VS2012 to this directory (checked - it's in there)
I clicked Manage WebSite > Browse
This shows an error:
HTTP Error 403.14 - Forbidden The Web server is configured to not list
the contents of this directory.
I found on the web that I should enable Directory Browsing. I tried it.
Now it shows me my app root directory instead of loading the web app (that's not what I wanted...)
How to make IIS launch my web app?
You need to grant permission to that folder.
When i deploy on IIS i grant "network service" read write access to the folder
You will need to launch the IIS Management Console and within the Default Website, your website folder should hopefully be listed. Do a right click on the website folder and click "Convert to Application"
You may want to consider using Web Deploy as it will simplify the deployment process.
If it's an MVC app, then the default controller & action in the routing need to correspond with a controller & action in your app. By default this would be the Index action in HomeController. If your default is some other combination, change the defaults in the routing config.
If you have a home/index controller/action, then check your server is configured to run aspx pages. do this by simply creating a default.aspx with some text in it & see if it's served when you browse the folder.
Directory Browsing should be disabled, as it would allow someone to browse the files on your server. I know it's your localhost, but good practice & all that.
I finally found it. It wasn's an IIS problem. One of my colleagues added the following lines to the Web.config
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
...
</handlers>
...
</system.webServer>
Removing them fixed the problem.

Resources