I am creating a prototype app at this url:
https://chirobyte.azurewebsites.net
It's a single page app. I am also using a bundler to minify and bundle my css and javascript files:
#Styles.Render("~/bundles/css")
#Scripts.Render("~/bundles/jquery")
#Scripts.Render("~/bundles/bootstrap")
#Scripts.Render("~/bundles/mustache")
#Scripts.Render("~/bundles/app")
Everything works fine in IE But if I try to load the page in Chrome, the very first time it loads, it is fine. But if I refresh it, I get some strange errors in Chrome. This is a screenshot of the errors I am getting:
There is no information with these errors. All I see under the status is "(failed)". The response is blank, and the preview is blank. The strange thing is that if I take any of these urls listed above, and copy/paste them into the address bar in Chrome, the content comes up just fine without any errors.
One thing to note here too - I just started to add my cache manifest file (https://chirobyte.azurewebsites.net/manifest/appcache). I'm not sure if that has anything to do with it or not. The timing of these errors seems to coincide with me putting that in there. But even if I take the cache manifest out completely, it still gives me these errors.
I'm not really sure where to go from here. The errors give me no information whatsoever. Am I doing something wrong with the bundling? Or could my cache manifest have something to do with it?
Thanks
p.s. - Just so you can see it, here is a screenshot from IE using the same url from above:
Related
I am working on a system that has a WPF WebBrowser that is displaying dynamically generated HTML.
This contains links to files, using file:///servername/filename.ext addresses.
This should have worked in times gone by when this was first developed, but does not seem to behave now.
What I can see:
White click on the generated file in the browser of being an HTML file: File is served from about:blank and in the Internet Zone. Clicking a link does nothing.
What I have done:
I have added about:blank to the Trusted Zone, and have set the security for the Trusted Zone to Low. Clicking a link still does nothing.
Created an HTML file and hosted it on my local IIS. Browse to this file in IE. The file contains a link to a file:/// address. Nothing happens on click.
Added http://127.0.0.1 to the Trusted Zone. The above test still fails.
Changed the generated HTML to be a link to http://www.google.com. This works.
What I think is happening:
The WPF WebBrowser is IE underneath. Did IE have a security update that stopped access to file:/// paths?
What I cannot do due to technical restrictions with deployment:
Have the generated HTML and the files linked to served by a web server so everything is within an http(s) environment.
What I can do:
Update browser settings
Update our code
Update - additional information:
The HTML is being displayed on the WPF by binding to a string that contains the HTML (effectively <html><body>Look! Stuff!<br />Whatever</html>)
file:///foo/whatever.txt exists and I have access to it
That file is generated by a process on a server and the client is generating the link to the file. This is a historic design, I didn't come up with it, I'm just maintaining it. I can't do massive code overhauls.
I cannot install any additional services anywhere
All Browsers have updated to prevent interesting stuff happening on local HTML files. Because you could do interesting stuff in the past it meant interesting exploits could be utilized too.
I've had a recent issue where I created a HTML in code and wanted to display it in CEFSharp (much better than WebBrowser by the way) with a link to CSS and JavaScript Files.
How I fixed it was to run a LocalHost and did this using this code which works really well: An HTTP file server (130 lines of code) in VB.Net
For testing your HTML outside of code you could run this batch file to start your LocalHost:
ECHO OFF
ECHO "Launching Localhost:8080"
py -3 -m http.server
ECHO "Loading HTML.."
start chrome localhost:8000
This batch file assumes you have Python 3+ installed. You can verify this in the Command Prompt with:
python --version
I've solved this by cheating a little.
I've got the VM to write the HTML out to a file, and then pass the file name to the browser in the view. This means that I am displaying the created content from file:////foo.htm, and that is fine for links to file:///server/bar
I have a very weird problem.
I've been creating my application and building it and running it. Chrome pops up with its tab and the page loads.
The last things I can remember installing before the app went haywire is Unity.
So now, I build, I click run in Chrome and the VS doesn't show any pages. The IIS express is running to point where I can query for pages like Home/Index but when I query my JsonResult Blog/Blogs I get a 500 error. I've used fiddler and I can hit the standard URLs but not my JsonResult.
Usually if you're on a page editing it, then you hit F5, chrome will load up that page in the browser. VS isn't doing that anymore.
The only thing I can pin it down to is Unity.....
If in the Fiddler response you cannot pinpoint the exact reason why your server returned 500 error you may try debugging your code. So start by enabling all errors. In VS use Ctrl+D+E and then make sure that Common Language Runtime Exceptions is selected:
Now F5 into your application, click Continue on all potential exceptions you don't recognize, and then in the browser navigate to the controller action that unleashed the 500 error. Chances are that the debugger will pinpoint you to the precise reason of this unhandled error.
NOTE: Don't forget to turn off the breaking on all Common Language Runtime exceptions settings once you have identified the problem or you might get flooded with lots of verbose errors.
NOTE2: Usually you don't need to resort to this heavy debugging artillery, just by inspecting the error response in Fiddler/Web developer toolbar of your webbrowser, you could come to the conclusion.
It was due to the last thing I added: Unity.
Just as an FYI, the reason no errors were coming back is because none of the controllers serving up my pages had an interface injected into them.
The only controller that had an interface injected into it was the toolbox controller and that was getting accessed via this JSON call. The response that was coming back was a HTML page but you could only view that in the Chrome network tab of the console.
The TinyMCE control for RichTextEditor properties in the Umbraco back-office do not show in Chrome, but are visible in other browsers. The text editor box is just missing entirely.
The Chrome console shows the error
SyntaxError: Unexpected token <
on the page tinymceCompress.aspx
Looking into the source of this file in Chrome Dev Tools, the HTML output for an ASP.NET error page is being appended to the end of the file. The error is:
Server cannot append header after HTTP headers have been sent.
I have manually read the reponse to the tinymceCompress.aspx in Fiddler for both Chrome (not working) and IE (working), and the reponse is exactly the same. There is no ASP.NET error message appended to the bottom of either response.
The control used to show in all browers, it is only recently that it appears to have broken. To our knowledge, we have not modified the Umbraco install.
This is Umbraco 4.11.9.
If you haven't found the answer yet, try looking in the Tiny MCE javascript files. I recall a while ago running into a file which was in the Umbraco release which had a misplaced SCM merge snippet (looks something like <<<). I think it may have been a similar issue.
EDIT: To add to this, you may be able to do a text search across all the scripts that are loaded and look for something like this:
<<<<<<< HEAD
or
>>>>>>> branch_name (as an example)
I had same issue in upgrading Umbraco v4.5.2 to v4.11.9. If you upgrade it from v4.5.2 to v4.11.10 the issue won't happen in Chrome any more.
I've got a really vexxing problem with an ASHX handler that renders a captcha image. The thing that makes it really vexxing is that it was working fine two months ago and when I went back to it again today it had stopped working.
What I've got is a page that throws in a captcha every so often. This is the markup from an example of a challenge:
<img class="challengedtl" src="Challenge.ashx?tkn=0057ea27-4d35-4850-9c6f-7a6fdc9818e2"/>
The GUID references a record in a SQL table that contains the actual content of the captcha as well as the status of the captcha challenge, i.e. has it been processed and if so did the user get it right etc.
On the page where this markup is found, the image displays as a broken jpeg. When I drop a breakpoint in the ASHX ProcessRequest() method I can see that the ASHX is never being called.
When I take the URL out of the source attribute and run it directly from the address bar in my browser, then I hit my break point in ProcessRequest and the captch image is rendered just fine.
I don't believe that my ASHX code is the problem, since it works when I call it directly. The problem seems to be with why the ASHX isn't being called by the main page. Given that this was working in February I am at a loss to explain what is going on.
I know that something has happened to my machine since then. I suspect a Windows Update or a service pack for something. The reason for this is that my captcha processing includes tracking the IP address of the caller. Back when this was working my local host was being registered as 127.0.0.1 (IPv4) but now it is being registered as ::1 (IPv6). Probably a red herring.
Does anyone know what might be causing this or do you have any suggestions for how to troubleshoot this problem?
Is the handler in the same folder as the page containing the html you posted above?
Here are the two key parts:
When I drop a breakpoint in the ASHX ProcessRequest() method I can see that the ASHX is never being called.
and
src="Challenge.ashx?tkn=0057ea27-4d35-4850-9c6f-7a6fdc9818e2"
Put those together, and what we can surmise that the path in your src attribute is wrong.
It's just an image tag. If the html loads it will send a request for that resource. Since your breakpoint is not hit, it can only mean that either you aren't testing somewhere that allows breakpoints or that it's sending the request to the wrong place.
It could be as simple as sending the request to the production version of the site, using the wrong schema (ie: https vs http), or missing a folder or port number somewhere. The browser should be able to give you the entire path of the resource -- make sure this matches what you expect.
I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]
The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx
It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?
I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.