Subject: [Tools-discuss] legacy http links in https://tools.ietf.org/ should move to https

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 May 2014 12:43:29 -0400

hi good tools folks--

i notice that many of the hyperlinks in https://tools.ietf.org/ point to
somewhere within http://tools.ietf.org, and other cleartext sites rather
than using https where possible.

We should be encouraging the use of https if possible.  If you want to
provide http links when the overview page is served via http, and https
when the page is served via https, you can just remove the scheme (so
the URL would look like href="//tools.ietf.org/whatever") or you could
remove the scheme and the host itself (so the URL would look like
href="/whatever").

here is a list of all the http:// sites (with a count of the number of
times they appear):

      1 http://aaa-sec.com
      1 http://bap.googlecode.com
      1 http://beta.iana.org
      1 http://fenron.net
      3 http://greenbytes.de
      1 http://lyx2rfc.org
      2 http://mail.tools.ietf.org
      1 http://pypi.python.org
      1 http://rtg.ietf.org
      2 http://svn.tools.ietf.org
     36 http://tools.ietf.org
      1 http://vinegen.com
      1 http://wiki.python.org
      1 http://www.anfdata.cz
      4 http://www.arkko.com
      1 http://www.ericsson.com
      1 http://www.google.com
      2 http://www.ietf.org
      7 http://www.isi.edu
      1 http://www.isoc.org
      1 http://www.itunes.com
      1 http://www.nao.ac.jp
      1 http://www.netnod.se
      1 http://www.rfc-editor.org
      1 http://xml.resource.org

derived from:

 grep 'href=["'\'']http:' index.html  | \
   sed -r 's_.*href=["'\''](https?://[^/"'\'']*)[/"].*_\1_' | \
  sort | uniq -c

Of these, the following sites appear to offer valid https today:

bap.googlecode.com
greenbytes.de
mail.tools.ietf.org
pypi.python.org
svn.tools.ietf.org
tools.ietf.org
wiki.python.org
www.google.com
www.ietf.org
www.isi.edu
www.isoc.org
www.itunes.com
www.netnod.se
www.rfc-editor.org

thanks for maintaining the IETF tools infrastructure,

	--dkg

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 23 May 2014 07:33:56 +0000

Hi,

in my datatracker development branch, I've changed all URLs to be protocol relative (http://www.paulirish.com/2010/the-protocol-relative-url/).

It requires more testing, but will result in everything staying on HTTPS once we enable HSTS.

Lars

On 2014-5-22, at 18:43, Daniel Kahn Gillmor <[email-masked]> wrote:

> -- 
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please reports datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
> Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
> send email to [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 May 2014 08:48:11 -0400

Thanks for doing this.

Eggert, Lars <[email-masked]> wrote:
    > in my datatracker development branch, I've changed all URLs to be
    > protocol relative
    > (http://www.paulirish.com/2010/the-protocol-relative-url/).

    > HTTPS once we enable HSTS.

Do we already generate https: in any emails we send out?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 23 May 2014 10:49:36 -0400

> in my datatracker development branch, I've changed all URLs to be protocol relative (http://www.paulirish.com/2010/the-protocol-relative-url/).

Thanks!  There are some external links to sites that don't offer https,
though -- the ones that are in the first list but not the second in my
earlier e-mail (e.g. lyx2rfc.org).  If you set those links to be
protocol-relative, they're likely to fail.

> It requires more testing, but will result in everything staying on HTTPS once we enable HSTS.

Once you enable HSTS, everything in the sites on which you've enabled
HSTS will stay on HTTPS anyway, for any HSTS-enabled browser :)

if you've got an URL that includes a hostname, and you know that host
offers https, it's probably better to go ahead and explicitly include
the https, rather than using protocol-relative.  Why possibly send
someone to the cleartext version of an external site if you know that
site supports https?

	--dkg

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 23 May 2014 14:54:50 +0000

Hi,

> protocol-relative, they're likely to fail.

right, hence the need for more testing.

Also note that your email was about tools.ietf.org, whereas I work on datatracker.ietf.org. The tools page is Henrik's alone (AFAIK).

Lars