If I have a link I'm trying to preload, e.g.
<link rel="preload" href="http://example.com/example.js">
and I don't know if example.com is an HTTP or HTTP2 server. Does the preload specification do anything if it's only HTTP?
Yes preload can be used by both.
Some servers use the preload header to implement HTTP/2 push. See here for an explanation for Apache HTTP/2 push and here for how Cloudflare are doing this in a similar manner on a customised version of Nginx.
However there are also many use cases for using it outside of HTTP/2 by the browser. For example to preload fonts from other domains (HTTP/2 push obviously only works from your server) - that doesn't need HTTP/2 but just needs browser support - not great at the moment as basically just Chrome and Opera but WebKit (used by Safari) have just implemented it so should be rolled out soon enough though Mozilla/Firefox have not yet and neither have Microsoft/Edge.
Smashing Mag have a great article on this subject and why browser usage and HTTP/2 server usage complement each other and are useful for different use cases.
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.
Is it possible to tell your HTML5 Webapp to not load the site from the appcache, if the client has network connection?
This isn't exactly what you're asking, but a way to achieve this is to set up a FALLBACK from / to for example /offline/index.html and then check in the offline index.html if you're online and if you are redirect back to /. That way your normal site is loaded over the internet and your offline version is loaded only when offline.
FALLBACK:
/ /offline/index.html
NETWORK:
*
PS. I have never tried this exact setup, and never even used FALLBACK urls, however I worked a lot with appcaches, so I am pretty sure this should work.
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/
Does anyone know how to setup kaazing websockets for use with IE and firefox? My app works great in Safari and Chrome but I can't get it to work with these two browsers. It just gives me a WebSocket is not defined error.
According to their website, I thought all you needed was to add:
<head>
<meta name="kaazing:postMessageBridgeURL"
content="http://www.example.com/bridge/PostMessageBridge.html" >
</head>
But I put the file there and still, it is failing.
You only need that tag you mentioned if you intend to do cross-origin connectivity in IE6 and IE7.
But if you just want basic WebSocket to work in those browsers the thing you need to do is include the WebSocket.js or ByteSocket.js files. In summary, if you intend to use text messages, then put this in your HTML page:
<script src="/html5/WebSocket.js"></script>
If you intend to use binary messages, then do this instead:
<script src="/html5/ByteSocket.js"></script>
This is more fully explained in the documentation here for typical usages of WebSocket:
https://kaazing.com/getting-started/
Regards,
Robin Zimmermann
Kaazing Product Management
Which version of the gateway are you using?
The step you mentioned is only required if you are integrating with another web server (like Apache). Is that what you're doing?
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.