5 ms·

> For example, the input string http://你好你好.在线/./a/../b/./c http://xn--6qqa088eba.xn--3ds443g/./a/../b/./c should be normalized to the string https://xn–6qqa088

> For example, the input string http://你好你好.在线/./a/../b/./c http://xn--6qqa088eba.xn--3ds443g/./a/../b/./c should be normalized to the string https://xn–6qqa088eba.xn–3ds/b/c https://xn--xn6qqa088eba-l19f.xn--xn3ds-zu3b/b/c Why would normalization change http:// http:// to https:// https:// ?

ramon156 2y ago
Because its 2024
- marginalia_nu 2y ago
  http:// http:// is not a typo for https:// https://. There's still a fairly large amount of web servers that do not talk https, and you simply cannot assume that they do. That will leave you with a lot of dead links. Besides, most that accept both will auto-renegotiate to https.
  - TacticalCoder 2y ago
    > There's still a fairly large amount of web servers that do not talk https, and you simply cannot assume that they do. OTOH I'm browsing since years forcing HTTPS only and life goes on fine. If the absolute worse comes to worse, I can use archive.is or archive.org but it's very rare that I need that. Basically: if a link is HTTP to me it's not worth opening. The one exception would be Debian packages URLs: but these are signed and the signatures are verified. User _apt is the only one allowed to emit HTTP traffic. This prevents my ISP or anyone else injecting nasty stuff.
    - forgotmypw17 2y ago
      Just because it is accessible to you does not mean it is accessible to everyone else. HTTPS has many failure modes which make it unreliable for essential access, such as time mismatches, certificate expirations, ssl version mismatches, etc. Security and privacy are important, and they are also not absolute. Sometimes the risk is outweighed by the importance of being able to access essential resources and reading material.
    - Analemma_ 2y ago
      User preferences should not be encoded into parser behavior, that’s nuts. You wouldn’t just arbitrarily change an ftp:// link to an imap:// link, so why would you accept it here? That exists at a whole other layer of the stack.
      - dmd 2y ago
        They would arbitrarily change an ftp:// link to an sftp:// link and then complain that it didn't work.
chrismorgan 2y ago
There’s got to be some accidental mangling there. Somewhere. Because of that error, and still more because of the blatant error in the next sentence: > For example, given the base string http://example.org/foo/bar http://example.org/foo/bar, the relative string http://example.com/ http://example.com/ leads to the final URL http://example.org/example.com/ http://example.org/example.com/. That’s just… no. I do not believe I have ever encountered any software which would parse it in that way, and I refuse to believe such software ever existed. It would be <http://example.com/ http://example.com/>. But the PDF matches the HTML. I dunno, something weird is going on. Look at the hyperlinks there, too, “http://” http://xn--ivg but not the rest of the URL that follows, and how the -- has been changed to –. Something went wrong somewhere in the editing or publication.
- silvestrov 2y ago
  My guess is that the html formatter changed the text "example.com" into "http://example.com http://example.com" to make it a valid absolute URL.
  - chrismorgan 2y ago
    Anything that turns </example.com/> into <http://example.com/ http://example.com/> should be shot. I dislike automatic linkifiers, especially in technical contexts, because they get things wrong so often, as regards what is a link at all (and certainly never linkify if there’s no protocol! “example.com/foo” should not be turned into <http://example.com/foo http://example.com/foo>), and as regards what can be part of the link (largely around trailing punctuation). Just require explicit delimition, like <…>, or else it’s text. (Markdown’s […](…) is bad because ) is part of URL code points, meaning parentheses in URLs won’t be percent-encoded by a normal serialiser, so then its parser gets messy trying to compensate, assuming that parentheses will normally be paired in URLs. Your delimiter needs to not be part of the set of URL code points.) HN’s auto-linkifier is, most of the time, one of the better ones (it was bad ten years ago, but got fixed around punctuation inclusion a few years ago), but it still has problems. I noticed too late that it mangled something in my comment: where you get http://xn--ivg http://xn--ivg, that xn--ivg is ”, because what I actually wrote was … too, “http://” but not …

ramon156 2y ago

Because its 2024

marginalia_nu 2y ago
http:// http:// is not a typo for https:// https://. There's still a fairly large amount of web servers that do not talk https, and you simply cannot assume that they do. That will leave you with a lot of dead links. Besides, most that accept both will auto-renegotiate to https.
- TacticalCoder 2y ago
  > There's still a fairly large amount of web servers that do not talk https, and you simply cannot assume that they do. OTOH I'm browsing since years forcing HTTPS only and life goes on fine. If the absolute worse comes to worse, I can use archive.is or archive.org but it's very rare that I need that. Basically: if a link is HTTP to me it's not worth opening. The one exception would be Debian packages URLs: but these are signed and the signatures are verified. User _apt is the only one allowed to emit HTTP traffic. This prevents my ISP or anyone else injecting nasty stuff.
  - forgotmypw17 2y ago
    Just because it is accessible to you does not mean it is accessible to everyone else. HTTPS has many failure modes which make it unreliable for essential access, such as time mismatches, certificate expirations, ssl version mismatches, etc. Security and privacy are important, and they are also not absolute. Sometimes the risk is outweighed by the importance of being able to access essential resources and reading material.
  - Analemma_ 2y ago
    User preferences should not be encoded into parser behavior, that’s nuts. You wouldn’t just arbitrarily change an ftp:// link to an imap:// link, so why would you accept it here? That exists at a whole other layer of the stack.
    - dmd 2y ago
      They would arbitrarily change an ftp:// link to an sftp:// link and then complain that it didn't work.

chrismorgan 2y ago

There’s got to be some accidental mangling there. Somewhere. Because of that error, and still more because of the blatant error in the next sentence: > For example, given the base string http://example.org/foo/bar http://example.org/foo/bar, the relative string http://example.com/ http://example.com/ leads to the final URL http://example.org/example.com/ http://example.org/example.com/. That’s just… no. I do not believe I have ever encountered any software which would parse it in that way, and I refuse to believe such software ever existed. It would be <http://example.com/ http://example.com/>. But the PDF matches the HTML. I dunno, something weird is going on. Look at the hyperlinks there, too, “http://” http://xn--ivg but not the rest of the URL that follows, and how the -- has been changed to –. Something went wrong somewhere in the editing or publication.

silvestrov 2y ago
My guess is that the html formatter changed the text "example.com" into "http://example.com http://example.com" to make it a valid absolute URL.
- chrismorgan 2y ago
  Anything that turns </example.com/> into <http://example.com/ http://example.com/> should be shot. I dislike automatic linkifiers, especially in technical contexts, because they get things wrong so often, as regards what is a link at all (and certainly never linkify if there’s no protocol! “example.com/foo” should not be turned into <http://example.com/foo http://example.com/foo>), and as regards what can be part of the link (largely around trailing punctuation). Just require explicit delimition, like <…>, or else it’s text. (Markdown’s […](…) is bad because ) is part of URL code points, meaning parentheses in URLs won’t be percent-encoded by a normal serialiser, so then its parser gets messy trying to compensate, assuming that parentheses will normally be paired in URLs. Your delimiter needs to not be part of the set of URL code points.) HN’s auto-linkifier is, most of the time, one of the better ones (it was bad ten years ago, but got fixed around punctuation inclusion a few years ago), but it still has problems. I noticed too late that it mangled something in my comment: where you get http://xn--ivg http://xn--ivg, that xn--ivg is ”, because what I actually wrote was … too, “http://” but not …