Re: Is preferred over Is wrong?

Would changing to HTTPS create specific problems when we use the new hostname-based extension mechanism? I am really not an HTTPS expert, but I assume that the certificate would then have to cover the hostname-based URIs for reviewed extensions. 


martin hepp          @mfhepp

> On 21 Apr 2015, at 22:24, Dan Brickley <> wrote:
> Let me also answer this here, since I commented in
> already. The situation is as follows:
> "1. the official definition of each term is via a URL of
> the form e.g.''. These are the canonical
> identifiers terms.
> 2. the site happens to also work currently via https://
> 3. there is consensus amongst the partners that they
> markup (in whatever format) in which
> is written instead of to be
> perfectly ok. For specifics of actual support for this, see each
> company individually.
> 4. at this time we (the team) have not decided to promote
> the https: version of the site over the http: version, although this
> is generally an appealing idea. There are some peculiarities in the
> way the site is hosted and implemented which I want to investigate
> properly first (partially w.r.t. using a naked/apex/bare domain name
> with https)."
> Hope this helps clarify,
> Dan
> On 18 April 2015 at 15:59, Aaron Bradley <> wrote:
>> To use Thing as an example, both and
>> return a 200 response header.
>> Is http:// preferred though, and his https:// actually incorrect?
>> The Meusel and Heiko paper on fixing errors [1] buckets use of
>> "the https protocol" under common errors.  And a cogent Stack Exchange
>> answer [2] says that one should using http, saying "Typically, user agents
>> wouldn’t dereference these URIs."
>> So, sponsors/ontologists, what's the official story? :)
>> This keeps coming up because for many months now Google has been encouraging
>> webmasters to use https:// for their sites [4].  Because Google has tied
>> this explicitly to improved search engine rankings, the audience most likely
>> to consume and act on this information - search marketers - is the same
>> group most likely driving implementation on their site.  And
>> though it's conflating web page consumption with deferencing of URIs,
>> nonetheless webmasters have been observed using and
>> justifying doing so because of this Google initiative.
>> If https *is* incorrect, then there are thing that can be done to mitigate
>> against its use:
>> - State that preference or requirement for http:// in the documentation.
>> - Add a rel="canonical" statement to each page where the href
>> value uses the http:// form of the URL.  Not only would that send a clear
>> message to any human examining the canonical, but send a message ("a strong
>> hint" in the words of Google) to the search engines not to index the
>> https:// form, and so they wouldn't be as likely to surface in search
>> results (there are currently 1,890 URLs in Google, 31,000
>> in Bing).
>> - Tangentially, use of a canonical would also stop the propagation of
>> URLs (currently just one www page indexed in Google, but
>> 31,800 in Bing).
>> - 301 direct* to* - essentially
>> resolving all technical issues with one stroke.  Note that an open GitHub
>> issue [3] proposes redirecting* to* but doesn't
>> wrap a secure to non-secure redirect in this, and would actually redirect
>> " to".
>> [1] Robert Meusel and Heiko Paulheim, Heuristics for Fixing Common Errors in
>> Deployed Microdata
>> [2] https - Secure and non-secure Markup?
>> [3] CODE: redirect to
>> · Issue #4 · schemaorg/schemaorg
>> [4] Official Google Webmaster Central Blog: HTTPS as a ranking signal

Received on Wednesday, 22 April 2015 11:57:04 UTC