Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.
Related
I have a download link like so:
Foobar
This works fine when downloading a file on the same server, but when downloading from another server (Azure blob storage in this case) the filename stays as "foo.xls", even though the HTTP response comes back with the following header:
Access-Control-Allow-Origin: *
Is this by design or is there potentially another header I can to add to the HTTP response to get this to work?
Yes, it is by design that the CORS headers have no affect on the download attribute. There are only two browsers that support the download attribute, Firefox and Chrome, and both browsers have a different policy on cross-origin files.
Chrome versions prior to 65 actually did allow the download attribute on cross-origin files, without CORS headers, but Firefox chose not to, citing potential social-engineering attacks.
MDN documents this behavior for Firefox 20 under the download attribute section for the a tag, behavior that has not changed since.
In Firefox 20 this attribute is only honored for links to resources with the same-origin.
This Bugzilla report discussed the security concerns and the possibility of using CORS.
When the user clicks such a link, the user will be prompted if they
want to download. It seems very easy for the user to make the mistake
of thinking that something on the original website is being
downloaded, and not something from bank.com.
Would it be possible to implement it with same-origin and CORS
(Access-Control-Allow-Origin) in mind if you are questioning cross origin
security? This is very useful feature for web applications (create Blob
using JS and let user download it with some meaningful name)
Google was opposed to using CORS for this.
There's also this Bugzilla report, which summarizes their decision from the other bug report.
Also, cross origin downloads are working perfectly in Google Chrome.
Yes, and we think they're adding security bugs by doing that.
The Bugzilla issues don't seem to rule-out the possibility of using CORS for cross-origin download attribute support in the future, but right now using CORS headers does not do anything for the download attribute. It's possible that if other browsers start supporting the attribute, a consensus may yet be reached.
For sake of completeness, there is of course the Content-Disposition header which you can use to force a download from the other domain, but this does not provide the same functionality as the download attribute. It does have better browser support though.
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.
Is it good to implement website elements like css, javascripts, images or web links without the protocol?
For example: jquery.com offer the cdn-file without:
//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
Pro for using is, that they automatically use the current protocol (http or https). Even the links are shorter (okay, just 4/5 signs). Are there any cons or should I use it on my own website?
Is there any definition about how browsers deal with this kind of links (official standard)?
href without protocol (Protocol-relative URL) is used to remove the naggy warning of accessing unsecure content in IE.
But it'll cause double download in IE7 and IE8 (alas, WHY U NO SMART!!!).
The standard RFC3986 is mentioned in Paul Irish's article. But standard can only serve as a reference in web development, the browser vendors' implementations is more important. Websites like Can I Use, WebPlatform documents this info.
Do refer to these links:
http://www.paulirish.com/2010/the-protocol-relative-url/
http://blog.httpwatch.com/2010/02/10/using-protocol-relative-urls-to-switch-between-http-and-https/
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
I have noticed today for the first time that Chrome (and only Chrome) does not pay attention to protocol-relative URL references. For example:
<img src='//www.example.net/image.png />
should source as https when it appears on https pages, and should source as http when it appears on http pages. IE and FF are still working this way, but Chrome is now sourcing it only as
//www.example.net/image.png
so when it appears on an https page, the page becomes unsecure. Anyone else notice this recently?
Chrome does respect protocol relative URL's, looking at your example it is malformed (there is no closing ' on your path.
I would like to make a link from a web page to a file on a local filesystem and make it work in all browsers (or at least in Internet Explorer, Firefox and Chrome).
For example, the following works in Internet Explorer:
Info here
but not in Firefox and Chrome.
Is there a way to make a link that works in all browsers?
Or a way to use javascript to detect which browser it is and then display the appropriate link based on the filename?
Links to local files on pages that were retrieved via HTTP(S) are deliberately disabled in Mozilla/Firefox, because they can be a security risk, and have been used in attacks in the past.
You can override this behaviour, however. For details, see this article in MozillaZine.
try prefixing your url with file:///