Can IIS/ASP.net ignore the browserCaps section in a web.config?
I have an app that on testing servers and dev environment IE8 is reported correctly - but in deployment IE8 is not recognised and content is rendedered "downlevel".....
do settings in web.config conflict with browsers.ini?
I found out why this downlevel behaviour was happening. ASP1.1 has a bug where it will fail to recognise the browser when the BROWSER string is too long. Its not been fixed in 1.1, but 2.0 the browser recog works with the long string.
An interim step to get a 1.1 site working it to have a tool like ISAPI rewrite 'fix' the headers on the way in....
Related
I work on an ASP.NET web project which was migrated from target framework 3.5 to 4.5. After migration to 4.5 there is an issue with the redirecting of HTTP requests. A redirect from a called web page which is located in a subfolder causes a duplication of the root folder and subfolder in the called URL (but: no duplication with same code in 3.5). The affected subfolder is not registered as separate web application.
Hosted files are:
/WebAppRoot/SubfolderInWebApp/Page1.aspx
/WebAppRoot/SubfolderInWebApp/Page1.aspx.cs
/WebAppRoot/SubfolderInWebApp/Page2.aspx
/WebAppRoot/SubfolderInWebApp/Page2.aspx.cs
Page1 should redirect to Page2 using tilde (~) to address the root-relative path. Redirect call within /WebAppRoot/SubfolderInWebApp/Page2.aspx.cs is:
Response.Redirect("~/SubfolderInWebApp/Page2.aspx", false);
On my local machine using Microsoft Visual Studio and IIS Express the redirect points to
/SubfolderInWebApp/SubfolderInWebApp/Page2.aspx
On the test environment running IIS which hosts the app in WebAppRoot the redirect points to
/WebAppRoot/SubfolderInWebApp/WebAppRoot/SubfolderInWebApp/Page2.aspx
If I change the redirect call to
Response.Redirect("/Page2.aspx", false)
it works. But this is not really satisfying, knowing that it worked with the tilde before migration and keeping in mind that there are several other places in the application which work with the tilde (but not used in a redirect).
Here some details about my used setup:
local machine for development: Microsoft Visual Studio Professional 2017 15.9.49 (running IIS Express on local machine)
test environment: IIS 8.5.9600.16384
both setups use the
application pool ".NET v4.5 Classic" with .NET CLR version v4.0.30319 in classic pipeline mode
I wasn't able to identify possible reasons for this behaviour yet. As far as I understand the behaviour before the migration is the expected one. But I am not very experienced with ASP.NET, so maybe I misinterpret some information or I did not use the correct keywords in my search to find a solution. Also I did not identify issues in this list of breaking changes which could be the reason for the current behaviour. But maybe I am not aware of the impact of some statements in this list.
Any idea what might be wrong in my project? Is there an obvious configuration I miss? Is my expectation of the behaviour wrong? Thanks in advance for your help.
I solved it with help of Leo's answer here. The relevant control was firing an asynchronous postback which caused the described behaviour above.
When migration to 4.5 the HTTP module ScriptModule was removed from the web.config. Integrating this module again did not work for me and I wasn't aware of this. After defining the relevant control as PostBackTrigger by using the Triggers element within the UpdatePanel, it worked again:
<asp:UpdatePanel>
...
<Triggers>
<asp:PostBackTrigger ControlID="ControlWithSyncPostback" />
</Triggers>
</asp:UpdatePanel>
After this change everything works as expected again and there is no need to keep the ScriptModule declaration in the web.config (at least in my case).
I am using CKeditor via cdn //cdn.ckeditor.com/4.5.8/full/ckeditor.js.
I wish to enable a preset plugin and do not know how to go about it. i need clear code example.
I have seen this tutorial on using the cdn but it talks about local plugins.
Code snippet is one of the plugins I want to enable.
Working locally with CKeditor in laravel 5.2 is a lot of headache. I keep have this error SyntaxError: illegal character when I inmport my javascript files. My laravel view uses blade template engine. I do not have this issues with CDN imports.
I resolved the issue after many days. all the javascript(not only Ckeditor or Tinymce) files I imported in laravel always gave the syntaxError: illegal character like this
I notices that in every response a header information was automatically pasted as well as a funny character. I solved this using two major steps.
I opened all the javascript files using notepad++ and deleted the first line (usually comments) using backspace and type it back manually, then saved the files.
I realized the header info HTTP/1.1 200 OK was some how related to the server configuration. I switched form using the in-built server php artisan serve to virtual host on xampp. And everything works well.
NB: This problem has nothing to do with Laravel 5.x. I personally think that this problems arise due to the copying and pasting, and downloading of files from the server.
To benefit from the advanced features of a full flesh server, I decided to use virtual host in xampp for development.
I am very happy. Hope it helps!
Just wondering if anyone has successfully got ccnet 1.6.x running on an XP box (IIS 5.1). I have it installed and it builds projects (failing at the moment most likely due to file permissions), but for some reason the mapping in the web.config for showing the build XMLs via the dashboard does nothing. All I get are 404 errors. The same also goes for some projects loading of parameters, e.g. http://localhost/ccnet/server/local/project/someProject/ViewProjectParameters.aspx . Don't ask why the "server" is XP, but it is.
Well I figured out what the issue was. As it's IIS 5.1, I installed IIS Lockdown. I didn't realize that by default, URL paths with dots in them that aren't the file extension dot are disallowed by default. I set the [AllowDotsInPath] = 1 in the urlscan.ini and it works like a charm now.
I experience a problem with GWT 1.6 in IE8 (I have enabled native XMLHTTP support).
The scenario i this: The first time I enter a page, it renders fine with no problems. But in subsequent requests, the page fails with a JavaScript error:
Message: Exception thrown and not caught
Line: 5067
Char: 237
Code: 0
URI: http://someurl/somehashcode.cache.html
It happens in both standard mode and compatibility mode. The strange thing is that I do not experience the error when I run the application on localhost through the ASP.NET dev server. Only when I run it from a Windows 2003 server.
Does anyone have an idea, why this happens?
I would appreciate any kind of help - thanks in advance.
/Henrik
You always use the last version of stable release of GWT. This kind of error is from GWT compiler and you must report it to GWT team. Maybe this problem fixed in the last version of GWT.
I've seen the same issue, my feeling its coming from cached files. When the response is not from cached files I didn't see an exception.
I'm doing SSL to IE8. Microsoft have a fix you could try:
Internet Explorer file downloads over SSL do not work with the cache control headers
http://support.microsoft.com/kb/323308
Internet Explorer 7 and Internet Explorer 8
To resolve this issue in Internet Explorer 7 and in Internet Explorer 8, follow these steps:
1. Start Registry Editor.
2. For a per-user setting, locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
For a per-computer setting, locate the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
3. On the Edit menu, click Add Value.
4. To override the directive for HTTPS connections, add the following registry value:
"BypassSSLNoCacheCheck"=Dword:00000001
To override the directive for HTTP connections, add the following registry value:
"BypassHTTPNoCacheCheck"=Dword:00000001
5. Quit Registry Editor.
I'm having a bit of a hair-puller here.
I'm publishing a VS 2008 application to a server, to be installed via ClickOnce. So far, so good. It installs just fine. Then I added in a ClickOnce update checker - one that uses ApplicationDeployment to handle checking for & applying updates.
So far, so good.
Then, on some of the machines it was installed on, the updater wouldn't work. The error it returned was that the application had already been installed from another URI - which it wasn't.
After enough digging around, I found that:
URL 1: htfp://www.domain.com/app/myapp.application
URL 2: htfp://www.domain.dom/App/myapp.application
ClickOnce considers URLs 1 and 2 to be entirely different - even though "app" contains a capital A in URL 2, and both point to the same, valid .application file.
When I found that out I edited all our intranet links to point to an all-lowercase version of the URL, which is working for now, but there's always the chance that someone might install it from an "incorrect" URL - the only solution being to forcibly uninstall and reinstall the application from the correct URL.
How do I force the deployment URL ClickOnce checks against for updates? It seems to generate its manifest based on the URL it was installed from, so I'm not sure I can fix it from VS' end.
Thanks,
~ Wogan
Try this:
http://msdn.microsoft.com/en-us/library/16z3sw0x%28VS.80%29.aspx