I'm developing a website using ASP.NET Core MVC and Orchard Core. Right now I need to publish it on an IIS server. It works perfectly fine when using Visual Studio, but when I 'publish it' and then go on the website using the IP or the name, Firefox console tells me that :
The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.
or the same but instead of 'text', there is 'html'.
I have already went through those questions&answers:
Why am I getting a encoding error with my ASP.NET Core View?
The character encoding of the HTML document was not declared
And downloaded an extension called Fix Filed Encoding.
Here is my web.config :
My files on IIS :
My code for the _layout :
My Controller for the default page :
My startup.cs page :
And the error in firefox console (but in French) :
I observed the network of firefox and had this :
Could you help me or give me some hints
Thanks in advance !
So Orchard could not connect to the Databaseand could not recognize his own tables so I had to manually create them and it solved it.
Try to to set the responseEncoding attribute of the globalization element.
<configuration>
<system.web>
<globalization requestEncoding="utf-8" responseEncoding="utf-8"/>
</system.web>
</configuration>
Related
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.
The Favicon Generator assembles a package for webmasters to use in order to have icons available for many different devices. The page comes with a file called site.manifest which is linked to via the following tag in the web page's document <head>:
<link rel="manifest" href="site.webmanifest">
According to Mozilla: "The web app manifest provides information about an application (such as name, author, icon, and description) in a JSON text file. The purpose of the manifest is to install web applications to the homescreen of a device, providing users with quicker access and a richer experience."
Unfortunately if you are using Microsoft's Internet Information Services (IIS), you'll get a 404.3 error if you try and access the site.webmanifest file.
The exact error message is as follows: "The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map."
How can I properly serve site.webmanifest files in IIS?
By default, IIS does not serve any files that does not have a MIME map associated with it in its (IIS) core settings.
To address this challenge, you will need to map the .webmanifest file extension to its appropriate MIME type.
To accomplish this, open IIS and follow the steps below;
On the left hand side, select either your web site or the entire server in the "Connections" menu.
If you select the server, your MIME mapping will apply to every web site on the server.
If you select a web site, it will only apply to a single web site.
Next, select "MIME Types" from the IIS menu:
Once there, click "add..." from the right hand menu.
In the dialog box that opens specify .webmanifest in the file name extension box application/manifest+json in the MIME type box.
Click "OK".
Congratulations; you've just defined the MIME type for .webmanifest on IIS.
For Azure I added this as the web.config
<?xml version="1.0"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".json" mimeType="application/json" />
<mimeMap fileExtension=".webmanifest" mimeType="application/manifest+json" />
</staticContent>
</system.webServer>
</configuration>
For those using ASP.NET Core (I am using 2.1) you can configure the MIME types that can be served in the application Startup.cs file as per the static files docs:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
FileExtensionContentTypeProvider provider = new FileExtensionContentTypeProvider();
provider.Mappings[".webmanifest"] = "application/manifest+json";
app.UseStaticFiles(new StaticFileOptions()
{
ContentTypeProvider = provider
});
app.UseMvc();
}
Easier solution is to rename your manifest file to site.webmanifest.json and link as
<link rel="manifest" href="site.webmanifest.json">
IIS should already have a MIME Type for .json files
This is also helpful if deploying to Azure where its not so easy to change the IIS settings.
Adding to #Ben's answer: if you have a SPA you should put StaticFileOptions code into the UseSpaStaticFiles() call:
FileExtensionContentTypeProvider provider = new FileExtensionContentTypeProvider();
provider.Mappings[".webmanifest"] = "application/manifest+json";
app.UseSpaStaticFiles(new StaticFileOptions()
{
ContentTypeProvider = provider
});
I found that the IIS server had ".json" listed in the Request Filtering feature saying it was not allowed.
Removing that allowed the file to be served.
I have deployed Liferay 6.2 GA4 portal on WebLogic server 10.3.6.0. If the javascript.fast.load property is enabled, the packed javascript version is not got (downloaded) from /combo url. In web browser console the following errors are displayed:
GET https://www.mywebsite.cz/liferay-portal/combo/?browserId=other&minifierType=&languageId=en_US&b=6203&t=1448975784000&/liferay-portal/html/js/aui/color-base/color-base-min.js&/liferay-portal/html/js/aui/event-touch/event-touch-min.js&/liferay-portal/html/js/liferay/dockbar.js 404 (Not Found)
Uncaught TypeError: Cannot read property 'init' of undefined
Due to this for example dockbar doesn't work. From source code it looks like ComboServlet can't get servlet resources found in /combo url parameters. If javascript.fast.load is disabled, portal seems to work.
Weblogic.xml:
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"
>
<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<page-check-seconds>60</page-check-seconds>
</jsp-descriptor>
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>
<container-descriptor>
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.antlr.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.mozilla.*</package-name>
<package-name>org.xmlpull.*</package-name>
</prefer-application-packages>
<optimistic-serialization>true</optimistic-serialization>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
<context-root>/liferay-portal</context-root>
<library-ref>
<library-name>ext-portal-dependencies</library-name>
<specification-version>1.0</specification-version>
<implementation-version>1.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>
</weblogic-web-app>
Does anybody know what could be the problem? Some WebLogic or Liferay settings? Thanks for any idea or help.
I've had a comparable problem long ago on tomcat when there were problems with the temporary file path - e.g. it growing too long. This might happen in a deeply nested filesystem, or when the total path length is limited.
One of the path-length-limiting factors that I'm aware of is an encrypted home folder on Linux. Also, if the temporary filesystem runs full, the compressed file won't be written and consequently can't be served to the browser.
Check something along those lines, and please report back.
After several days of solving the problem I found the main cause of this problem was this:
Because the customer didn't want to have portal dependencies (portal-service.jar, portlet-api.jar, ...) as domain libraries, I deployed it as Java EE Shared Libraries. Obviously it works differently than I expected. So after persuasion of customer, I put liferay dependencies to domain lib folder and suddenly everything started to work.
I installed ColdFusion 11 Developer version (downloaded from Adobe site 3 months trial) on Windows 8.1 and IIS7. I got this error when trying to open the ColdFusion administrator (see below). Is there a step by step example on how to fix this?
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information:
Module CustomErrorModule
Notification SendResponse
Handler cfmHandler
Error Code 0x800700b7
Config Error Cannot add duplicate collection entry of type 'mimeMap' with unique key attribute 'fileExtension' set to '.air'
Config File \localhost\?\C:\inetpub\wwwroot\web.config
Requested URL localhost:80/administrator/CFIDE/index.cfm
Physical Path C:\inetpub\wwwroot\administrator\CFIDE\index.cfm
Logon Method Anonymous
Logon User Anonymous
Config Source:
4: <staticContent>
5: <mimeMap fileExtension=".air" mimeType="application/vnd.adobe.air-
application-installer-package+zip" />
6: </staticContent>
Remove the MIME type from web.config
<mimeMap fileExtension=".air" mimeType="application/vnd.adobe.air-application-installer-package+zip" /> and save the file. Restart IIS and that should fix the issue.
This happened to me as well after updating Coldfusion 11 to the upgrade 2 (patch),
somehow it reads web.config file under C:\Coldfusion11\cfusion\wwwroot
What I did was simply rename the web.config to something like web - error.config
IIS will skip this file and run just fine.
When the file exists, I couldn't even access MIME configuration from the IIS Manager, so removal or rename of that file was the solution for me.
It's also discussed in : http://blog.immanuelnoel.com/2014/09/22/busting-the-http-error-500-19-on-coldfusion-11-iis/ and probably a bug under initial coldfusion configuration.
Removing the mime type from the web.config was enough and its remaining content was all right in our case; please note that this was related to the ColdFusion sites in general and not with the ColdFusion Administrator. The problem started after upgrading from ColdFusion 10 (update level 11) to 11 (update level 0) (on IIS 7.5, Windows Server 2008 R2), having changed the connectors from old version to ColdFusion 11 (as the installation document indicates at "Verify your IIS configuration" section). It had two positive effects:
the cascading styles started being delivered correctly
the 500 Internal Error on the IIS "Windows Authentication" directories stopped appearing (we regarded also https://forums.adobe.com/thread/1031711)
Was it an upgrade? I had a similar problem. I had to manually disable my Coldfusion 9 handlers.
If your previous Coldfusion handlers are still active, and you don't want to remove them until you are confident 11 is stable you can deactivate them in the web.config file.
<handler>
<remove name="AboMapperCustom-somenumber" />
<remove name="AboMapperCustom-anothernumber" />
</handler>
The web.config file should be found in the root directory of each website.
How can we remove the server header response in IIS 8.0/8.5?
My current server report:
Microsoft-IIS/8.0
Microsoft-IIS/8.5
For IIS 7.0 I used the URLScan 3.1 however this is only supported for IIS 7.0 and not 8.x
There is another solution and in my opinion this solution is the best and safe.
You can use UrlRewrite module created by the Microsoft. The Url Rewrite module redirects your url and can also change your IIS server name in the response header.
You don't have to use redirect property. You can use just change the Server header value.
Here are the steps:
First, download UrlRewrite module from this link:
http://www.iis.net/downloads/microsoft/url-rewrite and install
it on your IIS server. After that, restart IIS by this command on cmd
console
iisreset /restart
Add the following item to the your web config file under the <system.WebServer> tag. You can write anything to the Value item as server name.
Finally we changed the IIS version name on the data's header. Restart IIS again. via cmd console.
Bonus: If you want to test your website to see if it is working or not... You can use "HttpRequester" mozilla firefox plugin. for this plugin: https://addons.mozilla.org/En-us/firefox/addon/httprequester/
PS: I tested it and it worked for me on the IIS server. Not on the has been created temproray IIS server by the Visual studio.
It is possible now to remove Server header from web.config starting from IIS 10.0 :
<security>
<requestFiltering removeServerHeader ="true" />
</security>
More details on how to remove all unwanted/unnecessary headers can be found here.
Please note that this hides server header from the "application", as do all the other approaches. If you e.g. reach some default page or an error page generated by the IIS itself or ASP.NET outside your application these rules won't apply. So ideally they should be on the root level in IIS and that sill may leave some error responses to the IIS itself.
Note there is a bug in IIS 10 that makes it sometimes show the header even with the modified config prior to 2019.1C. It should be fixed by now, but IIS/Windows has to be updated.
Add the below code in Global.asax.cs:
protected void Application_PreSendRequestHeaders()
{
// Remove the default Server header
Response.Headers.Remove("Server");
// Optionally, add your own Server header
Response.AddHeader("Server", "My-App/1.0");
}
This has been tested to work under IIS 8.5 and 10.0.
Unfortunately most of the recommendations you will find online for removing the "Server" header in IIS will not work for IIS 8.0 and 8.5. I have found the only working option, and in my opinion, also the best, is to use an IIS Native-Code module.
Native-Code modules differ from the more common Managed modules, as they are written using the win32 APIs rather than ASP.NET. This means that they work for all requests (including static pages and images) rather than just requests that past though the ASP.NET pipeline. Using a Native-Code module, it is possible to remove unwanted headers at the very end of the request, meaning that you can remove headers (including the "Server" header) regardless of where they have been set.
Binaries and source code of an example Native-Code module for removing headers in IIS 7.0 to 8.5 are available in the following article.
https://www.dionach.com/en-au/blog/easily-remove-unwanted-http-headers-in-iis-7-0-to-8-5/
Just use clear tag in custom headers segment in web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-Custom-Name1" value="MyCustomValue1" />
<add name="X-Custom-Name2" value="MyCustomValue2" />
</customHeaders>
</httpProtocol>
</system.webServer>
For dynamic headers, You can use this code in Global.ascx:
protected void Application_PreSendRequestHeaders()
{
Response.Headers.Remove("Server");
Response.AddHeader("Sample1", "Value1");
}
This is dead simple. Just create a custom module:
public class HeaderStripModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.PreSendRequestHeaders += (sender, args) => HttpContext.Current.Response.Headers.Remove("Server");
}
public void Dispose(){}
}
And then register in web.config or applicationHost.config if you want machine wide implementation.
<system.webServer>
<modules>
<add name="HeaderStripModule" type="MyNamespace.HeaderStripModule" />
</modules>
</system.webServer>
URLScan has been discontinued starting from IIS 7.5, since its functionalities are supposed to be available through "request filtering" option (feature added in IIS 7.5).
But the URLScan's 'Remove server header' option does not look like having any equivalent in "request filtering".
As said on this answer and this answer to you question, you can emptied the Server with URLRewrite instead, which remains available on IIS 8/8.5 (with some update required for having its UI in IIS administration console).
It turns out, looking at this blog, that URLScan can still be installed on IIS 8/8.5, if lack of official support is not an issue.
I have not tested myself. Here are the steps:
Install IIS 6 Metabase compatibility (if not already there)
Install Isapi Filters (if not already there)
Install URLScan (from download-able installer, not from web platform installer)
Configure URLScan through its ini file (by default in C:\Windows\System32\inetsrv\urlscan)
Maybe some iisreset or even a reboot should be done. URLScan should be visible in IIS among Isapi filters
In IIS Manager, at the server level, go to the Features view. Click on HTTP Response Headers. You can add/remove headers there. You can also manage the response headers at the site level as well.