Re: The ability to automatically upgrade a reference to HTTPS from HTTP

Yes - except I would do it the other way around - HTTPS resource
claims to be sameAs the HTTP resource.


HEAD https://example.com/example HTTP/1.1

HTTP/1.1 200 OK
Link: http://example.com/example; rel=http://www.w3.org/2002/07/owl#sameAs


So only the HTTPS resource can claim that it is equal to the HTTP - if
the HTTP claim it is equal to the HTTPS resource, we can't trust it
and ignore the header.

Caching should also then only write the "dual-cache entry" from HTTPS.



As we want caches to play along, perhaps a 'proper' relation like
rel=sameAs is better.  Obviously it should still only be trusted
between resources in the same domain name.


This solves one problem I have with Tim's proposal - where do you hear
about the https:// link? Is it just guessed, or did some other graph
use the https URI?

With Graham's proposal the browser can silently request the HEAD
https:// version of the URI, if he finds the sameAs relation,
certificates are in order (thus avoiding the broken vhosts) - great -
GET the https thing and redirect to that instead. If not? Well, you've
only done a HEAD.

We can add an additional link flag for 'no-autoredirect' or something,
for web applications that get in a funny state if you just redirect
blindly.



Possibly the client could also, when requesting a HTTP resource, ask
the server for something like
 Accept-Protocol: https

and get a redirect to the https URI if one is available - but this is
fragile as a man in the middle could simply strip out
that header and force the client to stay on the insecure line. The
advantage of this is that the redirect does not have to be to the same
hostname.




On 27 August 2014 14:49, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 8/27/14 6:47 AM, Graham Klyne wrote:
>>
>> On 23/08/2014 01:47, Mark Nottingham wrote:
>>>
>>> The first thing that comes to mind is HSTS -
>>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
>>> https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
>>> http://tools.ietf.org/html/rfc6797
>>>
>>> … which basically allows a client to securely discover when they should
>>> stop using http:// for a given hostname.
>>>
>>> IIRC the general feeling on the sort of approach you outline is that the
>>> horse has already bolted; we can’t make blanket, retroactive changes to the
>>> entire Web.
>>
>>
>> Rather than retroactive change, could something like this work?:
>>
>>    C: GET http:example.com/example HTTP/x.x
>>
>>    S: xxx ...  (2xx or 3xx)
>>    S:  :
>>    S: Link: https:example.com/example; rel=owl:sameas
>>
>> (I know the syntax isn't right, but I hope you get the idea.)
>>
>> #g
>> --
>
>
> +1
>
> Being explicit about the relations that connect the entities denotes by HTTP
> URIs is really the best long term approach.
>
> Link: https:example.com/example; rel="http://www.w3.org/2002/07/owl#sameAs"
> .
>
>
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

Received on Friday, 29 August 2014 10:15:39 UTC