It seems to me that HTML5 download links bypasses any registered Service-Worker? Is this intended design?
<a href="/assets/images/i_am_cached_by_service_worker.png" download>link</a>
Both in Chrome v.62 and in Firefox v.57 this seems to be the case.
In Firefox it says it picked the .png file from the browser cache (304, not changed) which lies beyond the service-worker layer (note: all files were served with no-cache originally).
In Chrome the download activity doesn't even show in the Network tab at all.
Only if I go to chrome://net-internals/#events do I see it and there it never calls i.e. "SERVICE_WORKER_START_REQUEST" which seemingly all other network activities does. It just bypasses the Service-Worker layer and goes straight to the server.
Note: If I make a traditional download link:
link
then it will be handled by Service-Worker just fine (assuming registered Service-Worker scope is at URL root).
2nd. Note: In my case the Service-Worker scope is NOT at root (/region/shop) and I use a workaround where I have every attachment links be within that same scope, ensuring it's handled by the Service-Worker, but from inside the Server-Worker itself I can re-direct that request to wherever suits me (outside of scope).
Hash '#' breaks browser download behavior however (when using just a normal href link or target="_blank") and is excluded from url in link element. Registered Service-Worker scope should therefor not include '#' char for SPA's. This is all a workaround however and doesn't answer the original question.
Related
Click Me
This used to work as a valid href attribute but it seems in the past few months it now shows an error in the console (I'm using Chrome):
Not allowed to load local resource: view-source: http://stackoverflow.com
I found some links from 2013 where this was once a bug in Chrome but said it was fixed.
Could someone point me to an authoritative source that can explain why this no longer works? I assume that this is security by the browser and not an angular issue (since view-source is whitelisted and used to work)
Looks like Chrome and Firefox (at least) disabled this within the past year or so
I found this thread, and these release notes explaining why and provides a timeline as to when the change took place.
Related StackOverflow question: File URL "Not allowed to load local resource" in the Internet Browser
Chrome responds with the "Not allowed to load local resource:" as a security protocol. I'm not sure why this used to work, but not now, though there is no real way around this unless web-security is disabled. There may be a different outcome on other browsers, but ultimately you are correct in thinking that it's Chrome's security.
The reason is that Chrome tries to preload URLs in background, to speed up your browsing experience.
If you open the DevTools after loading the page, the content of the items listed on the Resources tab may not be populated. This is also true of network requests on the Network tab. To see the fully populated resources on the Resources tab, first open the DevTools, then refresh the page, or navigate to the desired page with the DevTools open. Now select the html resource and it should be populated.
So ive been through several posts and searches, but im still at a loss for how to get Chrome to display images when the src attribute uses a file thats located on another server. Im getting the image and setting its path via a custom file browser that Im hooking into CKeditor with. Works fine in IE, just not chrome.
This is for an intranet, and some of the image content is stored off of the web server. Although IE displays fine, it seems that Chrome does not like to display images with the src attribute is of a format like
file://server_name/share_name/folder_1/file_1.png
Strange, even though Chrome will pass the users identity, so its not a security issue. Also, if I take the path and directly paste it in the url window of Chrome, it displays fine. Just not when a img src value.
If this was just a page on its own, I could use a custom handler and write to the response stream, but this needs to work with a content editor.
Id like to include Chrome since many of our users have it and use it daily, but our default is IE.
Are there any file url schemes, or Chrome settings that will override these issues?
The issue may not be the image or URL format. I'd wager that it's browser security restrictions.
To ensure that maliciously designed web pages can't access a user's local files, accessing any data from the user's filesystem (especially network drives) is generally disallowed in most modern browsers. (At least in their default configuration. There may be policies or runtime parameters to override these for testing purposes such as Chrome's --disable-web-security parameter, but these are purposefully difficult to turn off.)
If you want the content to display across all browsers, you'll likely need to deliver it via HTTP(s) like the rest of the page content.
In previous version of chrome, on a webpage with the following:
<script>
document.write('<plaintext>');
</script>
<img src="http://example.com/image.jpg">
the image would not be downloaded. At some point a chrome update changed this behavior. Now when I look at the network tab, I see the image is downloaded. (fiddle here: https://jsfiddle.net/doojunqx/)
I have a script that is on a page, I would like to use this script to stop the browser from downloading (using up network bandwidth) for images and other assets that are unwanted and below my script tag.
Mobify does something similar here:
http://cdn.mobify.com/mobifyjs/examples/capturing-grumpycat/index.html
As they say on the page "Open your web inspector and note the original imgs did not load." However, when I open chrome developer tools and look at the network tab, I see the original images ARE now loading. I'm not sure what version of chrome changed this, but I think it is recent, within the last month or two.
Is there any way to force chrome back to the old behavior? Or any other way to stop these unwanted assets from loading?
Thanks,
Great question, and you're correct that it is a recent change in Chromium that affected the plaintext tag behaviour. In versions up to and including version 42.*, the HTML document parser would not spawn an asynchronous parsing thread until an external resource was found in the original HTML document. Once such a resource was found, an asynchronous thread would be spawned that would aggressively download all resources references within the HTML.
The recent change simplified the parsing behaviour by moving all document parsing to the asynchronous thread which now kicks off automatically. Whereas before, using the plaintext tag would ensure that no resources would be loaded if it was inserted before the first external resource, the plaintext tag is now racy as resources will download up to the moment the plaintext tag is executed in the main HTML document. As there is a time delay for the script to execute, an unknown number of resources will be retrieved.
There is as of yet no solution to this new behaviour, nor is there a way to disable the preload scanner as you would like. You will need to rely on workarounds such as polyfills to control your resource downloads. This new behaviour is only present in all versions of Chrome >= 43.* and has not been implemented in Safari, Firefox, or other browsers.
I have a Razor MVC application that contains a link to open a PDF stored on a file server. My code works when I run it in Visual Studio but is not working when I try it on production on the same computer. I click the link and nothing happens, I can see the path when I hover over it though. There are no errors or anything. I've tried all browsers but only really care about IE.
View
Image when I hover over the link
Any ideas why this is not working?
Filesystem URLs from remote pages (i.e. pages on other protocols like http:// or even other directories in the file system) are blocked by modern browsers for security reasons.
Here is a page describing the behaviour for Firefox (along with reasons why it exists).
Internet Explorer has joined the ranks of these modern browsers:
By default, Internet Explorer prevents navigation to Uniform Resource
Identifiers (URIs) using the "file:" protocol when the current URL
matches the following conditions:
The current URL is opened in the Internet zone or the Restricted Sites zone.
The current URL uses a protocol other than "file:".
This is a security measure designed to
prevent malicious sites from accessing system file objects.
This can be changed, but only on a per-client basis (see the MSDN article for details.)
The download attribute on an anchor element should set the name of the downloaded resource to the value of the download attribute. In the current version of chrome, the download attribute doesn't, however, change the name. Is this not anymore supported? Anything changed?
Here is a post explaining the functioning of the download attrib: http://updates.html5rocks.com/2011/08/Downloading-resources-in-HTML5-a-download
If it worked as expected, the name of the downloaded resource would be MyGoogleLogo. It is, however, the last element (file) of the href.
It seems that the download attribute works only when the resource is retrieved via HTTP from the same server as the linking document. So if you have
<a href=foo.txt download=something.txt>xxx</a>
on a web page, it works, but if it is in a local file, it does not; neither does it work if a web page refers to a resource on another server. By “works” I mean setting the filename; even when it does not “work” in this sense on Chrome (or Firefox), it causes a pure download instead of navigation to the resource, i.e. the resource is downloaded as a file but not opened in the browser.
According to MDN info, “In Firefox 20 this attribute is only honored for links to resources with the same-origin.” This seems to apply to current Firefox, too, in the stronger sense that the download attribute is completely ignored for cross-origin requests.