- From: jose <jose.kahan@w3.org>
- Date: Wed, 27 Aug 2014 13:17:01 +0200
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Public TAG List <www-tag@w3.org>, SW-forum Web <semantic-web@w3.org>
Hi Tim, It makes sense to me that both http: and https: point to the same resource. This aligns to one of the proposals I had made for our server to support either http or https requests for the same resource, but do force a switch to https for protected resources. Some extra thoughts. * Caching / MIM It would be good that the browser knows this so that it caches only once the resource. Today, at least in firefox, both are considered different linked-content resources (e.g. an image) and have two different cache entries. You are making two requests for the same one. If we consider that both http: and https: point to the same resource, it would be good to share the same cache entry and it could even speed up the requests. On the other hand, if you have retrieved one of the linked contents (an image again) using http and then go to an https that includes the same image, you could potentially be open to a man-in-the-middle attack as the image came thru http. This could potentially be used to inject content to your browser and was one of the reasons why mixed content warnings appear. So it seems to be that here you'd like to have a priority of origin source, saying that for the same resource, the most restrictive one (https) should override the other one. * Built-in browser https "upgrade" feature It would be good that the browsers have this as in-built. A kind of "protocol override" so that you assume that the protocol you used to request the page is the same one for the linked-in resources that belong to the same server. This is important for legacy content that can't be updated. If you're using http to request a page that includes resources using https, you probably don't want to downgrade those resources. You do want to do that when requesting a page thru https that includes http resources. * Servers supporting HTTPS The popular add-on https-everywhere assumes that all servers support https for the same resources. This makes the browser take the initiative to request everything using https, including the linked content. However, when a server supports only http, this adds to the network traffic as it's a hit-and-miss approach. I don't think they are using HTTPS OPTIONS to find out the capabilities of a server. If a server has self-signed certificates, it's more confusing to the layman to see the "untrusted certificate" pop-up than to have used http directly. Not everyone with a web site will buy an official certificate, that's for sure. So my question here is if the browsers should take the initiative to use https or should it be the initiative of the server (like we do with switch-ssl on our servers today). --jose
Received on Wednesday, 27 August 2014 11:17:32 UTC