Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2018-03-08 09:32:04

Algaris
Member
From: England
Registered: 2006-01-27
Posts: 548

Re: https barrier to local dev testing on Safari

I used to use VirtualHostX before I started dabbling with Raspberry Pi Linux servers.

After reading this thread and the linked articles it looks like I’ll need to change the virtual hosts I use for development work.

Last edited by Algaris (2018-03-08 09:34:52)

Offline

#14 2018-03-08 21:27:38

bici
Member
From: vancouver
Registered: 2004-02-24
Posts: 2,086
Website Mastodon

Re: https barrier to local dev testing on Safari

P.S. With my MampPro on localhost all my test sites use: .dev with no issues under Safari or Firefox…


…. texted postive

Online

#15 2018-03-08 21:30:11

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,202
GitHub

Re: https barrier to local dev testing on Safari

bici wrote #309773:

P.S. With my MampPro on localhost all my test sites use: .dev with no issues under Safari or Firefox…

That sort of makes sense, hosts overrides the usual DNS resolution, if I remember correctly.

Offline

#16 2018-03-08 21:34:01

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,702
Website

Re: https barrier to local dev testing on Safari

bici wrote #309773:

P.S. With my MampPro on localhost all my test sites use: .dev with no issues under Safari or Firefox…

That’s what I thought too, but it stopped working for me a while ago and I’ve had to change them since…


TXP Builders – finely-crafted code, design and txp

Offline

#17 2018-03-08 21:38:15

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,202
GitHub

Re: https barrier to local dev testing on Safari

RFC2606 is your buddy here: tools.ietf.org/html/rfc2606#page-2

To safely satisfy these needs, four domain names are reserved as
   listed and described below.

                   .test
                .example
                .invalid
              .localhost

      ".test" is recommended for use in testing of current or new DNS
      related code.

      ".example" is recommended for use in documentation or as examples.

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

Offline

#18 2018-03-08 22:48:22

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,134
Website

Re: https barrier to local dev testing on Safari

bici wrote #309773:

P.S. With my MampPro on localhost all my test sites use: .dev with no issues under Safari or Firefox…

Hmm which OS are you running? On my old iMac, running macOS 10.11 + Safari 11 + Firefox 58, that worked, yes. It didn’t work anymore with Opera beta from late November (and the latest nightly from Firefox somewhere end of December). But on my new iMac, running macOS 10.13, that fails with Safari 11 + Opera release build (still works with Firefox 58 but not later). For Safari, that is because the macOS libraries have been updated. I never got to test that on macOS 10.12.

I switched all my local domains to use .local now.

gaekwad wrote #309774:

That sort of makes sense, hosts overrides the usual DNS resolution, if I remember correctly.

Nope. .dev seems to be hardcoded deep down to resolve to https (that is what I understand from the few articles posted upthread).


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#19 2018-03-08 23:02:35

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,202
GitHub

Re: https barrier to local dev testing on Safari

phiw13 wrote #309785:

Nope. .dev seems to be hardcoded deep down to resolve to https (that is what I understand from the few articles posted upthread).

Then perhaps I’m doing something wrong, cos my hosts bypasses the usual DNS resolution (I’m using Google Public DNS at my router)…

hosts here includes this line (temporarily, I’m not stalking you):

127.0.0.1		phiw13.dev

Name resolution works fine:

$ ping phiw13.dev
PING phiw13.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.033 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.019 ms
^C
--- phiw13.dev ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.019/0.028/0.035/0.006 ms

If I switch that hosts entry to a LAN IP that I know runs a web server:

$ ping phiw13.dev
PING phiw13.dev (10.1.1.67): 56 data bytes
64 bytes from 10.1.1.67: icmp_seq=0 ttl=64 time=0.896 ms
64 bytes from 10.1.1.67: icmp_seq=1 ttl=64 time=0.429 ms
64 bytes from 10.1.1.67: icmp_seq=2 ttl=64 time=0.398 ms
64 bytes from 10.1.1.67: icmp_seq=3 ttl=64 time=0.379 ms
64 bytes from 10.1.1.67: icmp_seq=4 ttl=64 time=0.374 ms
^C
--- phiw13.dev ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.374/0.495/0.896/0.201 ms

…and I’ll curl that new IP’s index page:

$ curl -O http://phiw13.dev/index.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   169  100   169    0     0  10476      0 --:--:-- --:--:-- --:--:-- 10562

…which looks like this:

$ cat ./index.html 
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>

traceroute checks out fine, one hop:

$ traceroute phiw13.dev
traceroute to phiw13.dev (10.1.1.67), 64 hops max, 52 byte packets
 1  polaris (10.1.1.67)  0.612 ms  0.337 ms  0.383 ms

Perhaps I should have said my local hosts overrides internet DNS resolution. I’m not doing anything special, as far as I know.

Offline

#20 2018-03-08 23:09:11

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,134
Website

Re: https barrier to local dev testing on Safari

gaekwad wrote #309789:

Then perhaps I’m doing something wrong, cos my hosts bypasses the usual DNS resolution (I’m using Google Public DNS at my router)…

But can you access that domain with a web browser?

I have (had actually) exactly that domain in my host file (and set up in my vhost.conf). ping and friends did work; but browsers? no nothing but that friendly message.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#21 2018-03-08 23:25:22

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,202
GitHub

Re: https barrier to local dev testing on Safari

phiw13 wrote #309792:

I have (had actually) exactly that domain in my host file (and set up in my vhost.conf). ping and friends did work; but browsers? no nothing but that friendly message.

In Safari 11, yep – it resolves to the local IP, no enforced SSL, shows me the Nginx homepage.

In Chrome 64, nope. In Firefox mainline and dev 59, nope. Tor, nope. I just discovered this since I wondered if it was browser-specific.

Offline

#22 2018-03-08 23:31:19

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,134
Website

Re: https barrier to local dev testing on Safari

gaekwad wrote #309795:

In Safari 11, yep – it resolves to the local IP, no enforced SSL, shows me the Nginx homepage.

on macOS 10.13.3? It fails with Safari here. As I said it works on 10.11 (and I don’t know about 10.12).


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#23 2018-03-09 12:28:13

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,202
GitHub

Re: https barrier to local dev testing on Safari

phiw13 wrote #309797:

on macOS 10.13.3? It fails with Safari here. As I said it works on 10.11 (and I don’t know about 10.12).

It works on 10.12.6, that’s what I’m running here.

Offline

#24 2018-03-09 16:14:34

bici
Member
From: vancouver
Registered: 2004-02-24
Posts: 2,086
Website Mastodon

Re: https barrier to local dev testing on Safari

for me: Safari Version 11.0.3 / MacOS Sierra 10.12.6


…. texted postive

Online

Board footer

Powered by FluxBB