- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Fri, 25 Oct 2013 08:08:08 +0200
- To: Cody Burleson <cody.burleson@base22.com>
- Cc: Linked Data Platform Working Group <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-kxziJnGdjUTwqZ2ehS7dAgVUmfJCh+ZiO5Ubiyg_Vzg@mail.gmail.com>
Hi Cody, On Sat, Oct 19, 2013 at 2:32 PM, Cody Burleson <cody.burleson@base22.com> wrote: > > Do you guys think it might be worthwhile to specify a best practice suggesting that the protocol portion of a canonical URI for a resource should always be expressed in http and not https? well, not always, but at least whenever the description of that resource is available through both HTTP and HTTPS. Yes, that sounds like a good idea, however... > Since implementers will likely be creating systems that generate URI structures based on the existing application context, I can see it being easy to capture the existing protocol, which may be https. But I kind of feel like it should be up to the web server to resolve http URIs to https when the URI is used to fetch a resource. I'm assuming you meant "up to the *client* to resolve..." . This is tricky, because the client is not in general allowed to infer anything from the internal structure of the URI, and what you suggest amounts to inferring that two URIs differing only by the http(s): part are necessariy equivalent. Furthermore, how would the client know that a given http: resource is also available through https: ? So I would not suggest that the client may freely choose to switch between http and https when "following its nose". On the other hand, making this explicit for each resource ( http://a.b/c owl:sameAs https://a.b/.c ) is tedious and ugly... May be we could specify an HTTP header where the server could specify that all URIs matching a given regexp have the http/https equivalence? May be we could use POWDER for thar? Pa > > > Thoughts? > > -- > Cody Burleson > > >
Received on Friday, 25 October 2013 06:08:37 UTC