Subject: [Tools-discuss] Mixed content error on new datatracker stylesheet

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Apr 2015 14:48:24 -0700

Blocked loading mixed active content
"http://fonts.googleapis.com/css?family=PT+Sans|PT+Mono|PT+Serif:400,700,400italic,700italic|PT+Sans+Caption&subset=latin,latin-ext"

Seems easy enough to fix by the strategic addition of an 's'.
Properly quoting the '&' with '&amp;' might also be a good idea.

The fallback fonts on Linux causes legibility to degrade a little more
than I like.  (I'm not a fan of the choice of the PT fonts - the
amount of ornamentation is high, making them better suited to print at
this size rather than screen disaply - but I respect that choice.)

Style nit: The summary table for drafts could use a max-width
directive on either the whole table or just the first two columns.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Apr 2015 00:00:54 +0200

Hi Martin,

> Properly quoting the '&' with '&amp;' might also be a good idea.

Fixed.  Thanks.

Please don't use the list as an issue tracker, there are links in the
list footer to the actual issue tracker.

> this size rather than screen disaply - but I respect that choice.)

,,:-)  We have different ideas about the degree of ornamentation provided
by the PT fonts, but I'll look for some better fallback fonts.

> directive on either the whole table or just the first two columns.

Url, please?

	Henrik

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Apr 2015 15:26:56 -0700

> list footer to the actual issue tracker.

You mean https://tools.ietf.org/tools/ietfdb/newticket ?

Every time I click on a trac link it takes so long to load that I
think that it's broken.  This one takes more than 15 seconds to get to
an error page; I thought it was broken after 5.

> by the PT fonts, but I'll look for some better fallback fonts.

As I said, this is largely down to taste.  Largely.

If the primary isn't broken, I don't think that you need to spend time
on fallback fonts that are hardly ever going to be seen.

>> directive on either the whole table or just the first two columns.

Not sure what you are looking for, but I tend to view this sort of
page on a fairly wide view:

https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/

On a very wide screen, the table layout tends to give an unnecessary
amount of space to those first two columns.

You can use empty <col> elements [1] and max-width directives [2] if
you want more precise control and to allow for more content in the
third column.  Or you could simply cap the width of the table, or the
page.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/col
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/max-width

p.s., the new look is otherwise a lot better.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Apr 2015 00:46:00 +0200

> You mean https://tools.ietf.org/tools/ietfdb/newticket ?

Yes.

> an error page; I thought it was broken after 5.

The problem is not at the server end.  Here I see a load time of about
1.4 s for that page.

> amount of space to those first two columns.

Ack, good point.  I'll tweak.

> third column.  Or you could simply cap the width of the table, or the

I'll probably look at a max-width in ems for the two first columns.

> p.s., the new look is otherwise a lot better.

Ok, good :-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Apr 2015 00:48:04 +0200

One more point inline:

> The problem is not at the server end.  Here I see a load time of about

The "Error" you see, is that you have to log in.  Reading more than
just one word of the error message might be worthwhile ,;-)

	Henrik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 22:24:33 -0400

> The problem is not at the server end.  Here I see a load time of about

This might be due to missing reverse DNS.

When i connect via IPv6 or IPv4 from a host with a functional reverse
DNS, (using "time wget -4 https://tools.ietf.org/tools/ietfdb/newticket"
or "time wget -6 https://tools.ietf.org/tools/ietfdb/newticket" to get
the 403 Forbidden response), i see completion times between 1.5 and 5
seconds.

When i connect from a host with broken (missing, non-responsive) reverse
DNS, i see times between 23 to 25 seconds.

Maybe trac is trying to do a reverse DNS lookup and waiting for it to
time out before rendering the page?

Also, i notice that when i hit 209.208.19.222 as tools.ietf.org, i get a
301 Moved Permanently redirection to trac.tools.ietf.org.  But when i
hit 64.170.98.42 as tools.ietf.org it goes ahead and renders the page
without the 301 redirection.  It seems a bit odd that the two different
hosts for tools.ietf.org should have such different configurations.

      --dkg

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Apr 2015 19:31:47 -0700

> This might be due to missing reverse DNS.

I don't know how you thought to check that, but that could be it.  I
can confirm that it is much faster from home, where I have a PTR
record.

Honestly, I'd given up on the site ever being usable.  (And 23-25
sounds right; my 15 seconds was on a pretty slow count.)

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Apr 2015 08:55:17 +0000

This should use a protocol-independent URL like we do for the other assets.

On 2015-4-13, at 23:48, Martin Thomson <[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: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2015 09:10:15 -0700

> This should use a protocol-independent URL like we do for the other assets.

I don't see why if everything runs on https://.  Protocol-independent
URLs are a hack for resources that need to be loaded on http:// and
https://.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Apr 2015 11:31:44 -0400

> DNS, i see times between 23 to 25 seconds.

i'm now seeing this delay on tools.ietf.org (64.170.98.42) when i have
no PTR, so it's not just the trac instance:

0 dkg@alice:~$ time wget -O/dev/null -S https://tools.ietf.org/html/rfc5322
--2015-04-30 11:19:19--  https://tools.ietf.org/html/rfc5322
Resolving tools.ietf.org (tools.ietf.org)... 64.170.98.42, 209.208.19.222, 2001:1890:123a::1:2a
Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 30 Apr 2015 15:19:35 GMT
  Server: Apache/2.2.22 (Debian)
  Content-Location: rfc5322.html
  Vary: negotiate,Accept-Encoding
  TCN: choice
  Last-Modified: Sun, 22 Feb 2015 05:40:56 GMT
  ETag: "3ca44f-277b3-50fa6bac4ca00;514f29e2abbe5"
  Accept-Ranges: bytes
  Content-Length: 161715
  Cache-Control: max-age=604800
  Expires: Thu, 07 May 2015 15:19:35 GMT
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=UTF-8
Length: 161715 (158K) [text/html]
Saving to: ‘/dev/null’

/dev/null           100%[=====================>] 157.92K  87.3KB/s   in 1.8s   

2015-04-30 11:19:44 (87.3 KB/s) - ‘/dev/null’ saved [161715/161715]

real	0m25.339s
user	0m0.040s
sys	0m0.016s
0 dkg@alice:~$ 

This is actually impacting my ability to work with the archive today :/
Is this something that can be fixed or at least diagnosed more closely?
I'm happy to provide testing and feedback of any proposed fixes since i
know not everyone has broken reverse DNS ready at hand :P

Should i file it as a ticket somewhere, or is this the right place to
address it?

        --dkg

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 30 Apr 2015 20:59:02 +0200

Hi Daniel,

> real	0m25.339s

Ouch!

> Should i file it as a ticket somewhere, or is this the right place to

[email-masked] or [email-masked] is perfect.

I thought I'd removed some config pieces that might cause reverse lookups
after Martin's report, but I'll have another look to see what could cause
those to be done, and if there's some more forceful way of preventing them.

Best regards,

	Henrik

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 Apr 2015 17:14:08 -0400

Is it possible that had some unintended side-effects?

xml2rfc (and http://xml2rfc.ietf.org/ ) appear to have died, and I
think it may have been ~2 or 3 hours ago...)

W

On Thu, Apr 30, 2015 at 2:59 PM, Henrik Levkowetz <[email-masked]> wrote:
> Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
> Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 Apr 2015 17:21:10 -0400

... and fixed now.

I didn't do the right thing and open a ticket or anything, mainly
because the timing aligned iwt this...

W