7 ms·

Server not found error when connecting. Tried removing the "-" but didn't work neither.

• Hemospectrum 12y ago
  Apparently the hyphen isn't there by mistake. Here's the blog source repo: https://github.com/Mattias-/Mattias-.github.io https://github.com/Mattias-/Mattias-.github.io Are you perhaps using a browser or a DNS stack that rejects this type of domain name?
  • th0br0 12y ago
    The question should probably be: which OS are you using? It's quite interesting... dig seems to resolve the domain just fine, but neither chrome, curl nor firefox seem to be able to open the page. (tested on Fedora/CentOS/Android)
    • blablablaat 12y ago
      Same here. My dnsmasq server responds with the domain name when I try it with 'host', but curl and firefox fail on Debian and Ubuntu with only that 1 DNS server in resolv.conf. Curl says "curl: (6) Could not resolve host: mattias-.github.io". However, curl and firefox seem to be RFC-compliant. RFC952 states: "The last character must not be a minus sign or period."
    • jwatte 12y ago
      Android, Google chrome, also have the resolver problem.
  • steveklabnik 12y ago
    Firefox on Debian here, also get a "Problem loading page"
    • cipher0 12y ago
      Firefox on Arch, same stuff. Edit: Google Chrome works.
  • vortico 12y ago
    I had the same problem, but you can read the page from the Markdown-parsed source. https://github.com/Mattias-/Mattias-.github.io/blob/master/_posts/2015-01-03-DIY-Make-Your-Own-Programming-language.markdown https://github.com/Mattias-/Mattias-.github.io/blob/master/_...
  • randunel 12y ago
    Ubuntu 14.04 / Chrome + Firefox... same behaviour :( DNS resolves, curl + both browsers fail. randunel@18:~$ curl Mattias-.github.io curl: (6) Could not resolve host: Mattias-.github.io randunel@18:~$ dig +short Mattias-.github.io github.map.fastly.net. 185.31.18.133
    • anindyabd 12y ago
      Interesting... I'm on Ubuntu 14.04 too, and Firefox fails for me, but Chrome succeeds.
  • anaphor 12y ago
    I got it with curl -I 185.31.18.133 --header "Host: mattias-.github.io"
• stringy 12y ago
  According to RFC 1034[1] hyphens can only be interior to a label; it appears many tools simply follow these recommendations strictly. The exact wording is: "They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen." [1]: http://www.ietf.org/rfc/rfc1034.txt http://www.ietf.org/rfc/rfc1034.txt
  • teddyh 12y ago
    The wording “must start with” doesn’t sound like a “recommendation”, and I would think that these tools are right to interpret the standard strictly, and that Github is wrong to allow such domain names.
    • poizan42 12y ago
      Whatever happened to "be lenient in what you accept, conservative in what you send"?
      • teddyh 12y ago
        Github ignores that rule when they emit such domain names. One might make the point that Firefox and others who in turn reject such domain names are not being lenient in what they accept, but since domain names on the edge of acceptability often are a security issue, I think that a strict interpretation of the standard is the safe choice to make here.
      • MichaelGG 12y ago
        It's a terrible idea that just causes all sorts of intro l interop problems. Web development, for instance, is a mess because of all the various attempts to interpret stuff in some way, versus just failing.
• lelandbatey 12y ago
  I am also unable to visit the page. I'm on Android 4.2, using Firefox and Chrome.
• Pirate-of-SV 12y ago
  Author here: This is slightly embarrassing. I just added a custom domain/CNAME to my github pages so it should be reachable at http://blog.ppelgren.se http://blog.ppelgren.se
  • fcanela 12y ago
    Could happen to anyone. Nice job solving it fast.
• gue5t 12y ago
  In glibc's libresolv, this is caused by res_hnok in resolv/res_name.c returning 0: /* * Verify that a domain name uses an acceptable character set. */ /* * Note the conspicuous absence of ctype macros in these definitions. On * non-ASCII hosts, we can't depend on string literals or ctype macros to * tell us anything about network-format data. The rest of the BIND system * is not careful about this, but for some reason, we're doing it right here. */ #define PERIOD 0x2e #define hyphenchar(c) ((c) == 0x2d) #define underscorechar(c) ((c) == 0x5f) #define bslashchar(c) ((c) == 0x5c) #define periodchar(c) ((c) == PERIOD) #define asterchar(c) ((c) == 0x2a) #define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \ || ((c) >= 0x61 && (c) <= 0x7a)) #define digitchar(c) ((c) >= 0x30 && (c) <= 0x39) #define borderchar(c) (alphachar(c) || digitchar(c)) #define middlechar(c) (borderchar(c) || hyphenchar(c) || underscorechar(c)) #define domainchar(c) ((c) > 0x20 && (c) < 0x7f) int res_hnok(const char *dn) { int pch = PERIOD, ch = *dn++; while (ch != '\0') { int nch = *dn++; if (periodchar(ch)) { (void)NULL; } else if (periodchar(pch)) { if (!borderchar(ch)) return (0); } else if (periodchar(nch) || nch == '\0') { if (!borderchar(ch)) return (0); } else { if (!middlechar(ch)) return (0); } pch = ch, ch = nch; } return (1); }
  • gue5t 12y ago
    And the hack fix: /* hnokpre.c: LD_PRELOAD shim to bypass valid hostname checking in glibc gcc -fPIC -shared hnokpre.c -o libhnokpre.so LD_PRELOAD=./libhnokpre.so curl http://mattias-.github.io/ */ int res_hnok(const char* dn) { return 1; } int __res_hnok(const char* dn) { return 1; }
    • poizan42 12y ago
      I'm kinda wondering what's the reason for that that check to begin with. Just being pedantic for pedentrys sake?
    • deleted 12y ago
      [deleted]