Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #196872 > unrolled thread

Problems with https://manpages.debian.org/

Back to article view | Back to linux.debian.user

Contents

  Problems with https://manpages.debian.org/ Richard Owlett <rowlett@cloud85.net> - 2018-06-23 20:20 +0200
    Re: Problems with https://manpages.debian.org/ John Crawley <john@bunsenlabs.org> - 2018-06-24 02:30 +0200
      Re: Problems with https://manpages.debian.org/ Fred <fred@blakemfg.com> - 2018-06-24 03:10 +0200
        Re: Problems with https://manpages.debian.org/ (PS) John Crawley <john@bunsenlabs.org> - 2018-06-26 09:40 +0200
        Re: Problems with https://manpages.debian.org/ John Crawley <john@bunsenlabs.org> - 2018-06-26 09:40 +0200
          Re: Problems with https://manpages.debian.org/ Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-06-26 21:20 +0200
            Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) Reco <recoverym4n@gmail.com> - 2018-06-26 22:10 +0200
              Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) David Wright <deblis@lionunicorn.co.uk> - 2018-06-27 01:00 +0200
                Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) Reco <recoverym4n@gmail.com> - 2018-06-27 09:20 +0200
                  Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) David Wright <deblis@lionunicorn.co.uk> - 2018-06-28 05:30 +0200
                    Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) Reco <recoverym4n@gmail.com> - 2018-06-28 08:40 +0200
                      Re: Self-censorship 101 (was: Problems with  https://manpages.debian.org/) David Wright <deblis@lionunicorn.co.uk> - 2018-06-28 17:20 +0200
      Re: Problems with https://manpages.debian.org/ Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-06-24 03:20 +0200
      Re: Problems with https://manpages.debian.org/ David Wright <deblis@lionunicorn.co.uk> - 2018-06-24 04:10 +0200
      Re: Problems with https://manpages.debian.org/ <tomas@tuxteam.de> - 2018-06-24 09:50 +0200
    Additional info [Re: Problems with https://manpages.debian.org/] Richard Owlett <rowlett@cloud85.net> - 2018-06-24 10:10 +0200

#196872 — Problems with https://manpages.debian.org/

For the past couple of weeks I've had problems connecting to 
https://manpages.debian.org/ . Usually it went away after a couple of 
retries.

Earlier today had to do multiple retries over ~15-20 minutes.
If it's relevant, my ISP is T-mobile.
I haven't noticed any problems with other sites.

[toc] | [next] | [standalone]

#196874

On 2018-06-24 03:18, Richard Owlett wrote:
> For the past couple of weeks I've had problems connecting to 
> https://manpages.debian.org/ . 

Usually these days (last couple of months?) when I click a link in 
Firefox pointing to an online Debian manpage it takes a very long time 
to load, and sometimes drops out.
OTOH if I paste the address directly in the address bar it opens 
immediately.
I assumed it's a Firefox problem, though it's only the Debian site, and 
left it on my to-do list...

In other words, "me too".
-- 
John

[toc] | [prev] | [next] | [standalone]

#196875

On 06/23/2018 05:23 PM, John Crawley wrote:
> On 2018-06-24 03:18, Richard Owlett wrote:
>> For the past couple of weeks I've had problems connecting to 
>> https://manpages.debian.org/ . 
>
> Usually these days (last couple of months?) when I click a link in 
> Firefox pointing to an online Debian manpage it takes a very long time 
> to load, and sometimes drops out.
> OTOH if I paste the address directly in the address bar it opens 
> immediately.
> I assumed it's a Firefox problem, though it's only the Debian site, 
> and left it on my to-do list...
>
> In other words, "me too".
I am using firefox-esr (52.7.3) on Jessie and the above link opens 
immediately.
Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#196944 — Re: Problems with https://manpages.debian.org/ (PS)

On 2018-06-26 16:30, John Crawley wrote:
> On 2018-06-24 09:49, Fred wrote:
>> On 06/23/2018 05:23 PM, John Crawley wrote:
>>> On 2018-06-24 03:18, Richard Owlett wrote:
>>>> For the past couple of weeks I've had problems connecting to 
>>>> https://manpages.debian.org/ . 
>>>
>>> Usually these days (last couple of months?) when I click a link in 
>>> Firefox pointing to an online Debian manpage it takes a very long 
>>> time to load, and sometimes drops out.
>>> OTOH if I paste the address directly in the address bar it opens 
>>> immediately.
>> I am using firefox-esr (52.7.3) on Jessie and the above link opens 
>> immediately.
> Using firefox-esr in Stretch (52.8.1 btw, also in Jessie now) and just 
> clicked the above link ( https://manpages.debian.org/ ) in Thunderbird 
> to get the same spinning "Transferring data from manpages.debian.org" 
> and the tab still hasn't loaded after several minutes.
> 
> I also right-clicked the link, "copy link location" and pasted  it into 
> another tab's address bar. It appeared as exactly the same URL in the 
> address bar, but loaded immediately. Likewise if I select the text, 
> Ctrl+C, Ctrl+V in Firefox. Immediate.
> 
> I've only noticed this with the Debian manpages site though. URLs in 
> mail messages are usually opened instantly in a new non-focussed tab. 
> Maybe some addon some of us are using is getting in the way of Mozilla's 
> handling of link requests?
> 
> (That first tab still hasn't loaded why I've been slowly typing this.)
Restart Firefox with addons disabled and the problem goes away, so 
that's where to start searching I guess. Back to the todo list...

-- 
John

[toc] | [prev] | [next] | [standalone]

#196945

On 2018-06-24 09:49, Fred wrote:
> On 06/23/2018 05:23 PM, John Crawley wrote:
>> On 2018-06-24 03:18, Richard Owlett wrote:
>>> For the past couple of weeks I've had problems connecting to 
>>> https://manpages.debian.org/ . 
>>
>> Usually these days (last couple of months?) when I click a link in 
>> Firefox pointing to an online Debian manpage it takes a very long time 
>> to load, and sometimes drops out.
>> OTOH if I paste the address directly in the address bar it opens 
>> immediately.
> I am using firefox-esr (52.7.3) on Jessie and the above link opens 
> immediately.
Using firefox-esr in Stretch (52.8.1 btw, also in Jessie now) and just 
clicked the above link ( https://manpages.debian.org/ ) in Thunderbird 
to get the same spinning "Transferring data from manpages.debian.org" 
and the tab still hasn't loaded after several minutes.

I also right-clicked the link, "copy link location" and pasted  it into 
another tab's address bar. It appeared as exactly the same URL in the 
address bar, but loaded immediately. Likewise if I select the text, 
Ctrl+C, Ctrl+V in Firefox. Immediate.

I've only noticed this with the Debian manpages site though. URLs in 
mail messages are usually opened instantly in a new non-focussed tab. 
Maybe some addon some of us are using is getting in the way of Mozilla's 
handling of link requests?

(That first tab still hasn't loaded why I've been slowly typing this.)
-- 
John

[toc] | [prev] | [next] | [standalone]

#196960

Not to go off-topic, but you wrote:
"Difficult for me to judge. I do have over 13000 hostnames in /etc/hosts
which I hope has an accelerating effect on loading pages (though I"

So you aggressively flaunt conventional wisdom with this practice. What is your
secret? I have often thought of doing the same when DNS queries crawl, but it
seemed that surely if the answer was so simple, others would have
discovered it already ;-)
On Tue, Jun 26, 2018 at 2:30 AM John Crawley <john@bunsenlabs.org> wrote:
>
> On 2018-06-24 09:49, Fred wrote:
> > On 06/23/2018 05:23 PM, John Crawley wrote:
> >> On 2018-06-24 03:18, Richard Owlett wrote:
> >>> For the past couple of weeks I've had problems connecting to
> >>> https://manpages.debian.org/ .
> >>
> >> Usually these days (last couple of months?) when I click a link in
> >> Firefox pointing to an online Debian manpage it takes a very long time
> >> to load, and sometimes drops out.
> >> OTOH if I paste the address directly in the address bar it opens
> >> immediately.
> > I am using firefox-esr (52.7.3) on Jessie and the above link opens
> > immediately.
> Using firefox-esr in Stretch (52.8.1 btw, also in Jessie now) and just
> clicked the above link ( https://manpages.debian.org/ ) in Thunderbird
> to get the same spinning "Transferring data from manpages.debian.org"
> and the tab still hasn't loaded after several minutes.
>
> I also right-clicked the link, "copy link location" and pasted  it into
> another tab's address bar. It appeared as exactly the same URL in the
> address bar, but loaded immediately. Likewise if I select the text,
> Ctrl+C, Ctrl+V in Firefox. Immediate.
>
> I've only noticed this with the Debian manpages site though. URLs in
> mail messages are usually opened instantly in a new non-focussed tab.
> Maybe some addon some of us are using is getting in the way of Mozilla's
> handling of link requests?
>
> (That first tab still hasn't loaded why I've been slowly typing this.)
> --
> John
>

[toc] | [prev] | [next] | [standalone]

#196963 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

	Hi.

On Tue, Jun 26, 2018 at 02:14:36PM -0500, Nicholas Geovanis wrote:
> Not to go off-topic, but you wrote:
> "Difficult for me to judge. I do have over 13000 hostnames in /etc/hosts
> which I hope has an accelerating effect on loading pages (though I"
> 
> So you aggressively flaunt conventional wisdom with this practice. What is your
> secret? I have often thought of doing the same when DNS queries crawl, but it
> seemed that surely if the answer was so simple, others would have
> discovered it already ;-)

It is simple, but the implementation is questionable.

One can put all major banner networks, maybe Google, Facebook and their
friends into your /etc/hosts and point all those entries to 127.0.0.1.
Works wonders on loading Internet web-pages, although someone may
consider that "it can break web sites", or "it robs website owners of
their income", or some other such nonsense.


The main questions here are:

1) How does one obtains such site list.
Using any public source for this is suspiciously close to censorship.

2) Why bother with /etc/hosts at all, if one can use DNS or HTTP proxy
for the same purpose with much simplier configuration (hint - you cannot
block all sites in a domain via /etc/hosts unless you list all of them
there).

3) Why cripple system-wide resolver for a single program (in this
case - a browser). A suitable browser plugin should suffice here.

Reco

[toc] | [prev] | [next] | [standalone]

#196964 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

On Tue 26 Jun 2018 at 23:03:34 (+0300), Reco wrote:
> 	Hi.
> 
> On Tue, Jun 26, 2018 at 02:14:36PM -0500, Nicholas Geovanis wrote:
> > Not to go off-topic, but you wrote:
> > "Difficult for me to judge. I do have over 13000 hostnames in /etc/hosts
> > which I hope has an accelerating effect on loading pages (though I"
> > 
> > So you aggressively flaunt conventional wisdom with this practice. What is your
> > secret? I have often thought of doing the same when DNS queries crawl, but it
> > seemed that surely if the answer was so simple, others would have
> > discovered it already ;-)
> 
> It is simple, but the implementation is questionable.
> 
> One can put all major banner networks, maybe Google, Facebook and their
> friends into your /etc/hosts and point all those entries to 127.0.0.1.
> Works wonders on loading Internet web-pages, although someone may
> consider that "it can break web sites", or "it robs website owners of
> their income", or some other such nonsense.

I posted the rationale here last year:
https://lists.debian.org/debian-user/2017/10/msg00386.html

> The main questions here are:
> 
> 1) How does one obtains such site list.
> Using any public source for this is suspiciously close to censorship.

In the post above.

> 2) Why bother with /etc/hosts at all, if one can use DNS or HTTP proxy
> for the same purpose with much simplier configuration (hint - you cannot
> block all sites in a domain via /etc/hosts unless you list all of them
> there).

That's probably why it's so long. But do I want to set up a DNS proxy
on each host, with any wheezy, jessie and stretch differences to sort
out? Then I have to maintain my list of domains to send to localhost.
Where do I start with that?

> 3) Why cripple system-wide resolver for a single program (in this
> case - a browser). A suitable browser plugin should suffice here.

How long does it take to read ½MB into memory (once) and then check
it? Obviously not very long as it works well. A plugin means yet more
maintenance for me to do.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#196966 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

	Hi.

On Tue, Jun 26, 2018 at 05:51:27PM -0500, David Wright wrote:
> > 2) Why bother with /etc/hosts at all, if one can use DNS or HTTP proxy
> > for the same purpose with much simplier configuration (hint - you cannot
> > block all sites in a domain via /etc/hosts unless you list all of them
> > there).
> 
> That's probably why it's so long.

That's the only reason it's that long.

> But do I want to set up a DNS proxy
> on each host, with any wheezy, jessie and stretch differences to sort
> out?

Why would you? You set up a single DNS (or HTTP proxy) and point all
your devices there.
Setting up a local DNS resolver is justifiable for a laptop, of course,
provided you carry one with you into different networks.

> Then I have to maintain my list of domains to send to localhost.
> Where do I start with that?

My DNS of choice for small LAN segments is dnsmasq.


> > 3) Why cripple system-wide resolver for a single program (in this
> > case - a browser). A suitable browser plugin should suffice here.
> 
> How long does it take to read ½MB into memory (once) and then check
> it? Obviously not very long as it works well.

You misunderstood me, it seems. You make a change to the file that's
respected by each and every program that utilizes gethostbyname(3) and
gethostbyaddr(3).
The only positive thing that achieves is better browsing experience, and
the reason you do this is the brokenness of Modern Web™.
At the same time you get numerous side effects for every other program
in your system(s), which may or may not be problematic.


>  A plugin means yet more maintenance for me to do.

They say that one should not argue about tastes. So I won't.

Reco

[toc] | [prev] | [next] | [standalone]

#196985 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

On Wed 27 Jun 2018 at 10:17:11 (+0300), Reco wrote:
> 	Hi.
> 
> On Tue, Jun 26, 2018 at 05:51:27PM -0500, David Wright wrote:
> > > 2) Why bother with /etc/hosts at all, if one can use DNS or HTTP proxy
> > > for the same purpose with much simplier configuration (hint - you cannot
> > > block all sites in a domain via /etc/hosts unless you list all of them
> > > there).
> > 
> > That's probably why it's so long.
> 
> That's the only reason it's that long.

On further checking, the current hitlist of sites has 13531 hostnames.
A global edit in emacs and a  sort -u  yields a list of two-component
domains, and this edited list has 6765 items.

> > But do I want to set up a DNS proxy
> > on each host, with any wheezy, jessie and stretch differences to sort
> > out?
> 
> Why would you? You set up a single DNS (or HTTP proxy) and point all
> your devices there.

I can't guarantee that any particular machine at home is always
running as a proxy whenever I browse using an arbitrary machine
for browsing. My home isn't a business running a server 24/7,
and my consumer-grade router runs only DHCP, not DNS.

> Setting up a local DNS resolver is justifiable for a laptop, of course,
> provided you carry one with you into different networks.

I'm not sure what you mean. The only resolver at home is /etc/hosts,
which is very easy to maintain. I have a master list of local hosts
(PC/router/phone/printer/TV/roku devices) and the hitlist, and a
one-liner to install it (concatenate, and mangle the host's own
IP address).

> > Then I have to maintain my list of domains to send to localhost.
> > Where do I start with that?
> 
> My DNS of choice for small LAN segments is dnsmasq.

Sure. But who's going to generate the list of domains¹? As I said,
my edited list has 6765 items, but is unsuitable for use as is:
it might be sensible to block ads.youtube.com, but not youtube.com.

> > > 3) Why cripple system-wide resolver for a single program (in this
> > > case - a browser). A suitable browser plugin should suffice here.
> > 
> > How long does it take to read ½MB into memory (once) and then check
> > it? Obviously not very long as it works well.
> 
> You misunderstood me, it seems. You make a change to the file that's
> respected by each and every program that utilizes gethostbyname(3) and
> gethostbyaddr(3).
> The only positive thing that achieves is better browsing experience, and
> the reason you do this is the brokenness of Modern Web™.
> At the same time you get numerous side effects for every other program
> in your system(s), which may or may not be problematic.

I'm not aware of any other program that's 1% as promiscuous as a
browser. (Perhaps you could suggest some.) OTOH there are legitimate
sites that block my traffic on occasion, eg Cox (my ISP) and Debian
blocking my "spam" on the basis of blacklistings.

> >  A plugin means yet more maintenance for me to do.
> 
> They say that one should not argue about tastes. So I won't.

I'm not sure who's arguing. You asked three questions and I'm trying
to answer them in a way that reveals my motives. So if I install a
suitable plugin, how do I choose it and where do I obtain the list
of domains² to block?

Cheers,
David.

¹-² I've posted the source of my hostname hitlist; perhaps someone
will post the source of a similar kind of domain hitlist.

[toc] | [prev] | [next] | [standalone]

#196988 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

	Hi.

On Wed, Jun 27, 2018 at 10:25:34PM -0500, David Wright wrote:
> > > But do I want to set up a DNS proxy
> > > on each host, with any wheezy, jessie and stretch differences to sort
> > > out?
> > 
> > Why would you? You set up a single DNS (or HTTP proxy) and point all
> > your devices there.
> 
> I can't guarantee that any particular machine at home is always
> running as a proxy whenever I browse using an arbitrary machine
> for browsing. My home isn't a business running a server 24/7,
> and my consumer-grade router runs only DHCP, not DNS.

A router seems a natural place to host DNS (to me at least). If it's
impossible for whatever reason - then things are tough, but are not
hopeless. Any cheap/free VPS will solve it.


> > Setting up a local DNS resolver is justifiable for a laptop, of course,
> > provided you carry one with you into different networks.
> 
> I'm not sure what you mean. The only resolver at home is /etc/hosts,
> which is very easy to maintain. I have a master list of local hosts
> (PC/router/phone/printer/TV/roku devices) and the hitlist, and a
> one-liner to install it (concatenate, and mangle the host's own
> IP address).
> 
> > > Then I have to maintain my list of domains to send to localhost.
> > > Where do I start with that?
> > 
> > My DNS of choice for small LAN segments is dnsmasq.
> 
> Sure. But who's going to generate the list of domains¹?

The same person who it for your /etc/hosts, of course. Who else?


> As I said,
> my edited list has 6765 items, but is unsuitable for use as is:
> it might be sensible to block ads.youtube.com, but not youtube.com.

Any DNS can contain a custom A/AAAA record ('host block') or a custom
NS/SOA record ('domain block'). DNS adds you options, it does not take them.


> > > > 3) Why cripple system-wide resolver for a single program (in this
> > > > case - a browser). A suitable browser plugin should suffice here.
> > > 
> > > How long does it take to read ½MB into memory (once) and then check
> > > it? Obviously not very long as it works well.
> > 
> > You misunderstood me, it seems. You make a change to the file that's
> > respected by each and every program that utilizes gethostbyname(3) and
> > gethostbyaddr(3).
> > The only positive thing that achieves is better browsing experience, and
> > the reason you do this is the brokenness of Modern Web™.
> > At the same time you get numerous side effects for every other program
> > in your system(s), which may or may not be problematic.
> 
> I'm not aware of any other program that's 1% as promiscuous as a
> browser. (Perhaps you could suggest some.)

Let's see. Any torrent client. Any MTA. SSH client. Tor/I2P/Freenet
instance. A Modern Desktop Environment™.

As I wrote earlier, it may, or may not be a problem. I take it that it
for you it is not.

Reco

[toc] | [prev] | [next] | [standalone]

#196998 — Re: Self-censorship 101 (was: Problems with https://manpages.debian.org/)

On Thu 28 Jun 2018 at 09:38:21 (+0300), Reco wrote:
> 	Hi.
> 
> On Wed, Jun 27, 2018 at 10:25:34PM -0500, David Wright wrote:
> > > > But do I want to set up a DNS proxy
> > > > on each host, with any wheezy, jessie and stretch differences to sort
> > > > out?
> > > 
> > > Why would you? You set up a single DNS (or HTTP proxy) and point all
> > > your devices there.
> > 
> > I can't guarantee that any particular machine at home is always
> > running as a proxy whenever I browse using an arbitrary machine
> > for browsing. My home isn't a business running a server 24/7,
> > and my consumer-grade router runs only DHCP, not DNS.
> 
> A router seems a natural place to host DNS (to me at least). If it's
> impossible for whatever reason - then things are tough, but are not
> hopeless. Any cheap/free VPS will solve it.
> 
> 
> > > Setting up a local DNS resolver is justifiable for a laptop, of course,
> > > provided you carry one with you into different networks.
> > 
> > I'm not sure what you mean. The only resolver at home is /etc/hosts,
> > which is very easy to maintain. I have a master list of local hosts
> > (PC/router/phone/printer/TV/roku devices) and the hitlist, and a
> > one-liner to install it (concatenate, and mangle the host's own
> > IP address).
> > 
> > > > Then I have to maintain my list of domains to send to localhost.
> > > > Where do I start with that?
> > > 
> > > My DNS of choice for small LAN segments is dnsmasq.
> > 
> > Sure. But who's going to generate the list of domains¹?
> 
> The same person who it for your /etc/hosts, of course. Who else?

I have no relationship with this person.

> > As I said,
> > my edited list has 6765 items, but is unsuitable for use as is:
> > it might be sensible to block ads.youtube.com, but not youtube.com.
> 
> Any DNS can contain a custom A/AAAA record ('host block') or a custom
> NS/SOA record ('domain block'). DNS adds you options, it does not take them.

That wasn't my point. If I'm to use this list as a starting point,
I would have to examine each address to determine whether to block
the entire domain (eg expedia.com, youtube.com) or just the hosts
(eg ads.expedia.com, ads.youtube.com). That's a lot of work.

> > > > > 3) Why cripple system-wide resolver for a single program (in this
> > > > > case - a browser). A suitable browser plugin should suffice here.
> > > > 
> > > > How long does it take to read ½MB into memory (once) and then check
> > > > it? Obviously not very long as it works well.
> > > 
> > > You misunderstood me, it seems. You make a change to the file that's
> > > respected by each and every program that utilizes gethostbyname(3) and
> > > gethostbyaddr(3).
> > > The only positive thing that achieves is better browsing experience, and
> > > the reason you do this is the brokenness of Modern Web™.
> > > At the same time you get numerous side effects for every other program
> > > in your system(s), which may or may not be problematic.
> > 
> > I'm not aware of any other program that's 1% as promiscuous as a
> > browser. (Perhaps you could suggest some.)
> 
> Let's see. Any torrent client.

I don't have any, so I can't judge whether the hitlist would be useful
for reducing the number of adverts, or be harmful to its functionality.
Trying to serve other people's clients with a PC that has problems
coping with ads/counters/etc itself would be rather futile, I'd think.
And where would I store all these fragments of data for others to
download?

> Any MTA.

We've discussed this here before. A "home user" is likely to submit
mail through a smarthost and receive it via a POP/IMAP server (or
use webmail) rather than running an MTA. It strikes me that you're
probably posting as a "non-home user" who's hardly likely to be
running a browser on such out-dated hardware, or lack a 24/7 server
for handling incoming email.

> SSH client.

Why should a SSH client be promiscuous?

> Tor/I2P/Freenet instance.

Similar argument to torrent. BTW I do recall that using services such
as these were forbidden when I was a "non-home" user.

> A Modern Desktop Environment™.

No idea why a DE should be promiscuous, but it sounds like a good
reason to avoid using one. (Or is it related to the ™.)

Look at the list of hosts in the list. 2000 contain 'ads', 350 contain
'count', 450 contain 'click', and hundreds of the domainnames are not
really suitable for pre-watershed viewing. As you said, "one should
not argue about tastes". :)

> As I wrote earlier, it may, or may not be a problem. I take it that it
> for you it is not.

Yes, and I suspect that many others may share my opinion. I'm not
sure why this was described as "So you aggressively flaunt
conventional wisdom with this practice", having received no follow-
ups from that quarter.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#196876

On 6/23/18, John Crawley <john@bunsenlabs.org> wrote:
> On 2018-06-24 03:18, Richard Owlett wrote:
>> For the past couple of weeks I've had problems connecting to
>> https://manpages.debian.org/ .
>
> Usually these days (last couple of months?) when I click a link in
> Firefox pointing to an online Debian manpage it takes a very long time
> to load, and sometimes drops out.
> OTOH if I paste the address directly in the address bar it opens
> immediately.
> I assumed it's a Firefox problem, though it's only the Debian site, and
> left it on my to-do list...
>
> In other words, "me too".


It might not be the case here depending on the how's it and what's
being clicked, but I've been having an ongoing problem with links
sitting there spinning, too.

*In my case*, I've noticed it's a lot about redirects taking seemingly
forever. That's about clicking from an open email or from a search
engine.

The other instance which still normally includes redirects are any
links that retain the user tracking information attached at the end as
part of their formation. I'll see those spin for a half hour or more
then load reasonably well, almost instantly (considering it's dialup)
if I manually remove that tracking information and try again.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

[toc] | [prev] | [next] | [standalone]

#196877

On Sun 24 Jun 2018 at 09:23:13 (+0900), John Crawley wrote:
> On 2018-06-24 03:18, Richard Owlett wrote:
> >For the past couple of weeks I've had problems connecting to
> >https://manpages.debian.org/ .
> 
> Usually these days (last couple of months?) when I click a link in
> Firefox pointing to an online Debian manpage it takes a very long
> time to load, and sometimes drops out.
> OTOH if I paste the address directly in the address bar it opens
> immediately.

When you say "click a link in Firefox", the address that the link
points to is often very different from what you may think. For
example, if you're on a Google search results page (I've used
"debian man apt"), one of the top hits points at
https://linux.die.net/man/8/apt (in green, under the link),
and the status bar shows that address (at the bottom of the page),
but the link actually goes to
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwiX2fDzjOvbAhUCY6wKHdPsA-AQFghUMAM&url=https%3A%2F%2Flinux.die.net%2Fman%2F8%2Fapt&usg=AOvVaw1qYRaYckElVn8OyErQkgTb
which means that google goes through a whole load of machinations
before it actually goes off to where you wanted it to.

Having clicked on the link (with either mouse button), the status
bar will now automagically show the real (long) address instead of
the desired (short) one like it did before.

When I can get away with it, I have a habit of copying the location of
the links that point at files, and using my wgt bash function which
throws away the everything up to "url=", translates the % sequences,
and leaves me to rubout the trailing noise (&usg=AOvVaw1qYRaYckElVn8OyErQkgTb
in my example). wgt finishes by calling wget. If you're lucky, the
file is downloaded along with its metadata.

> I assumed it's a Firefox problem, though it's only the Debian site,
> and left it on my to-do list...

Difficult for me to judge. I do have over 13000 hostnames in /etc/hosts
which I hope has an accelerating effect on loading pages (though I
think it's why I can't click on google's paid links).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#196878

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 24, 2018 at 09:23:13AM +0900, John Crawley wrote:
> On 2018-06-24 03:18, Richard Owlett wrote:
> >For the past couple of weeks I've had problems connecting to
> >https://manpages.debian.org/ .

FWIW, less than two seconds for me. I've Javascript disabled (yes,
really disabled, in about:config, after voiding the silly Firefox
warranty).

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsvS4kACgkQBcgs9XrR2kaqBQCfa8EViOBZ/h2X9xp/GGKhDWBM
XPgAnR1sFifGBaLUmuH/X3rs9Le6EPaK
=lOSm
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#196879 — Additional info [Re: Problems with https://manpages.debian.org/]

On 06/23/2018 01:18 PM, Richard Owlett wrote:
> For the past couple of weeks I've had problems connecting to 
> https://manpages.debian.org/ . Usually it went away after a couple of 
> retries.
> 
> Earlier today had to do multiple retries over ~15-20 minutes.
> If it's relevant, my ISP is T-mobile.
> I haven't noticed any problems with other sites.
> 

After seeing the comments about redirection and eliminating tracking 
info I took a second look.

What is in my bookmarks
    http://manpages.debian.org/cgi-bin/man.cgi
Where I get to
    https://manpages.debian.org/

I'll continue to use the first for the time being.
If/when it responds slowly I'll stop it and try the second bookmark.
Also my browser is
User agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 
Firefox/52.0 SeaMonkey/2.49.1
Build identifier: 20171015235838

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web