8 ms·
Whose bug is it anyway?
- kohtatsu 6y agoIf the UA encounters a 404 it could offer to strip the ".", perhaps.
- henvic 6y agoAdding this could add unintended consequences. This is not an easy to solve issue. In reality, this is something that a clear RFC should deal with (or does and I don't know).
- bmn__ 6y agoNo, the server should offer it because the UA is clueless about the URI space. Apache httpd comes with mod_speling. https://httpd.apache.org/docs/mod/mod_speling.html https://httpd.apache.org/docs/mod/mod_speling.html
- gus_massa 6y agoThe problem is that it is difficult to know how many symbols it must fix. It can be also a comma, colons, semicolons, and parenthesis, and ... In HN I always put an space before and after each URL just in case because I never remember what the parser does with something like (http://www.google.com http://www.google.com).
- 082349872349872 6y agoAmong the ways in which the early web may have been an improvement upon its successors: https://www.w3.org/Addressing/URL/5.1_Wrappers.html https://www.w3.org/Addressing/URL/5.1_Wrappers.html
- thaumasiotes 6y agoI always delimit URLs with spaces. For example, I might punctuate your comment this way: > Among the ways in which the early web may have been an improvement upon its successors: https://www.w3.org/Addressing/URL/5.1_Wrappers.html https://www.w3.org/Addressing/URL/5.1_Wrappers.html . It's surprising to me that nobody else does this.
- edent 6y agoI think that's the sensible way to do it.
- jfk13 6y agoThat can result in unfortunate line breaks.
- thaumasiotes 6y agoSo? It can't lead to malformed URLs. Perhaps the Virgin marketing team could go the distance to send U+200C between the end of the URL and the punctuation following it, but I'm not going to.
- Dylan16807 6y agoKeep in mind that SMS is either 160 7-bit characters or 70 16-bit characters. It wouldn't fit.
- jwilk 6y agoU+200C is ZERO WIDTH NON-JOINER, which doesn't make sense in this context. Did you mean U+200B ZERO WIDTH SPACE?
- andreareina 6y agoI do, and I wouldn't be surprised if more people here do so as well. Then again, I also wouldn't be surprised at people here not doing so and expecting URL classifier to strip trailing punctuation even though the spec allows it.
- JadeNB 6y agoI also do it, because sometimes the parser does the 'right' think and sometimes it doesn't, and it's easier just never to rely on it. It's tough to fight when the parser thinks it's doing the right thing but isn't; for example, I literally couldn't find out how to send someone a link to https://en.wikipedia.org/wiki/Only_the_Super-Rich_Can_Save_Us https://en.wikipedia.org/wiki/Only_the_Super-Rich_Can_Save_U...! in Slack; the trailing ! is part of the URL, but Slack resolutely refused to recognise at such. (I don't know what HN's parser does, so I guess we can regard this as an experiment! EDIT: HN also refuses to recognise it. I tried the <> wrapper suggested elsethread, with amusing results: it makes HN's parser gobble both the ! and the trailing > as part of the URL! Maybe a percent-encoding would have been the way to go.)
- bmn__ 6y agoThis has been standardised in: https://tools.ietf.org/html/rfc3986#appendix-C https://tools.ietf.org/html/rfc3986#appendix-C So double quotes, angle brackets or whitespace are conforming/acceptable separators. I have known about this RFC for a long time and hence I have been practically applying it in the wild. Most software deals with the standard separators correctly, and the problem of unwanted trailing punctuation is mitigated.
- Nextgrid 6y agoThe biggest problem here is that the company involved is ran by monkeys and there's no way to report this issue. In a proper company this would either not have happened (if competent people were behind the feature and would've tested this properly) or would've been resolved the same day as soon as a customer reported the problem.
- caiobegotti 6y agoIf we are considering URLs have entered the realm of regular content we produce/consume as text, then the bug should be fixed by the lowest layer in the stack (dunno if it's the URI library or the OS a browser app or whatever). We can't expect people to understand the concept of a hyperlink while we scold them for not adding a blank space after them (which is stupid, we don't do that in regular text) or something like that. We need to handle URLs gracefully. I have seen legal papers with URLs at the end of sentences multiple times with period marks right next to them because a text editor works like that. The user is not to blame here. In theory the person who sent the SMS is not to blame either, SMS is a text document.
- user5994461 6y agoThe highlighting is done by the messaging app, it should be corrected by the messaging app. The issue is specific to messaging apps, in the context of text messages and copy/pasted URL, where an URL might get an extra dot as if concluding a sentence.
- deleted 6y ago[deleted]
- derefr 6y agoThe bug is with whoever decided to use a (greedy) URL parser as a URL recognizer. Those are two different tasks — like facial recognition vs. facial identification. "Drawing a box" that separates a face/URL from the rest of the image/prose, vs. actually "understanding" that face/URL. There should exist (and, I believe, do exist) algorithms specifically for segmenting micro-format data like URLs, phone numbers, etc., out of prose text. These algorithms are specifically tuned not just for the features of these micro-formats, but also for the features of prose text that might conflict with them (like trailing periods!) The output of such segmentation algorithms can then be fed to actual parser/scanner regexes, to validate and extract meaning from the microformats. (The segmentation algorithms don't always trigger only on valid instances of the micro-format, so you need a stricter check after.) One might then say that, having such an algorithm in hand, it's the responsibility of any API of a rendering engine that knows it's going to be used for rendering mixed prose+URL content (where the URLs aren't marked up in any way to indicate them), to offer an API for such a URL-segmentation algorithm, and in its docs to mention that this API should be used in place of just throwing the lower-level URL scanner at the problem. But that supposes that the implementers of such an API have such an algorithm in hand. Often they aren't even aware that such algorithms exist. Really, I would say that this is a "tragedy of siloed development": if this were a FOSS rendering toolkit, probably someone who knows about the existence of this algorithm would have raised an issue within a relevant repo; and then the folks working on the project could have taken a look and realized it would be better to offer/implement that API, and document its use-case (and warn, in the lower-level API, that it shouldn't be being used for the higher-level use-case.) But because this is a big opaque-from-the-outside project, there's no clear way for a meeting-of-the-minds between "the person that notices the bug and knows that prose:URL segmentation algorithms exist" and "the team that could benefit from that information" to happen. This is what bug bounty programs are for in security land—to provide a channel for this meeting-of-the-minds to happen. But there isn't really anything like this in UX land.
- izacus 6y agoNote that this "whoever" are the authors of Signal chat application which is completely opensource. The bug report for this was closed on a technicality that has very little to do with usability or even understanding the issue. But this is kinda standard with Signal developers - they are repeatedly giving me the feeling of not quite understanding usability while they build the app. Just think of the PIN verification mess and the mess that's their backup functionality.
- nkrisc 6y agoIt's the media team. They created an ambiguous URL given the context. When you're making a web page you control the context and markup so you can make it unambiguous. If you don't, and you're putting a URL at the end of a proper sentence, it becomes ambiguous.
- the_pwner224 6y agoThe media team do not know and should not be expected to know the exact minute details of how URLs can and cannot be validly formatted. Especially given that common parsers handle these cases in violation of the standards. Nobody ever uses URLs ending in a ., and for 99.999% of humans it is completely reasonable to write http://example.com http://example.com. It's a different thing to say that they should have at least tested it first.
- deleted 6y ago[deleted]
- bluedino 6y agoThey should be sending correct URL’s and testing their messages. It’s not like it’s the first one they’ve sent
- jlg23 6y ago> The media team do not know and should not be expected to know the exact minute details of how URLs Someone paid to communicate via digital media should understand the limitations of these media. The rule is pretty simple, old and does not require "exact minute details": Don't follow URLs with punctuation characters.
- rk06 6y agoMedia team is supposed to send correct message. And verify the message is correct. They don't need a CS degree to verify it.
- nkrisc 6y agoI would agree if this media team was responsible for only printed mailers. I suppose that no, they don't need to understand the basics of digital media and URL parsing to do their job, but they do to be good at their job.
- toast0 6y agoIt doesn't really matter whose bug it is. If you're sending urls through a lossy medium, and you want them to work, your server needs to be accepting of trailing garbage and (where possible) truncation and case insensitive. If you send a link via sms, some number of people are going to type it in a url bar while looking at their phone, that's a lossy process. In addition to whatever terrible things happened during sms transmission.
- thewebcount 6y agoThe issue is sending a bare URL. They should have said, “To visit our support page, click here.” With “click here” being a link. If they’re concerned about people with email clients that don’t support HTML mail, they should also put on a line by itself the full bare URL. This is email communication 101.
- namenotrequired 6y agoIt's an SMS, not email.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- jccooper 6y agoAll of the above. Any of those layers could have fixed the problem, and should have.
- betenoire 6y agoBut it is a valid url. 'Fixing it' in a deep layer would cause eventual regressions. The bug is in the interpretation of intent, which imo, clearly lies at the UI layer in this case. edit: it's not "clearly the UI layer" as I said... it should be fixed at the layer that transforms the text into structured data. That's where I'd put my tests
- Androider 6y agoAll of the involved parties should fix the problem on their own. Any single one of them fixing the issue won't prevent it from popping up again, since you can substitute or circumvent the fixed layer. Signal should handle this case explicitly in the app, since it's a common frustration for their own users when typing dots, commas and parenthesis. Android should maybe fix the library, but at the very least fix the documentation to mention that it is not intended to be used in context of prose. Android fixing their library is the least useful of all possible fixes, since it won't propagate to users of Android in any meaningful way for a decade. The Virgin web team should see that there's elevated 404's, and configure their system to ignore trailing full-stops. A company the size of Virgin probably already has a process to review marketing messages, but it's likely to be someone eyeballing it, and they should fix it to catch this automatically. They probably already use a marketing automation and scheduling system, that could fix it by verifying the links before pushing.
- bluedino 6y agoIf I was the web team I wouldn’t fix it. You have the chance of breaking some other thing that’s intended to work that way, and you’re guessing what the visitor wants to do, and shouldn’t assume
- Xylakant 6y agoAs the web team, you could specially redirect that one single URL. That wouldn’t make any assumptions on what the user wants - it’s clear they want to go to that specific URL.
- deleted 6y ago[deleted]
- bastawhiz 6y ago> Signal should handle this case explicitly in the app I'm not sure I agree with this. Eliminating the use of a system library because of single bug likely makes everything _worse_ in the end. You might work around this one bug, but how many other bugs might you be introducing? Or how many bug fixes will you miss out on because Android fixed something upstream? If every app has to implement its own URI parsing because the one provided by the system isn't perfect by default, you end up with an objectively worse situation than you started with. How many bugs around punycode or obscure query param parsing rules or unicode or URIs with credentials or new top-level domains will pop up because every app uses a different library with different behavior and different test suites, or a different version of each library? Android fixing their software _does_ actually make a difference, especially with recent versions of Android which update much more seamlessly than older versions have.
- gray_-_wolf 6y agoAnd this is why I always put space before the punctuation when sending a link to someone.
- barbegal 6y agoFor me it's fairly clear that the only unambiguous way of delimiting a URL in the context of plain text is using whitespace. Only a space, tab or new line shouldn't be considered as part of the URL. This means virgin media are at fault and should put a space after the URL.
- slaymaker1907 6y agoThere apparently is also an RFC someone mentioned earlier in the comments of this thread which says you can use double quotes “ https://news.ycombinator.com/reply?id=23951099&goto=item%3Fid%3D23926357%2323951099” https://news.ycombinator.com/reply?id=23951099&goto=item%3Fi... or angle brackets < https://news.ycombinator.com/reply?id=23951099&goto=item%3Fid%3D23926357%2323951099> https://news.ycombinator.com/reply?id=23951099&goto=item%3Fi....
- ademarre 6y agoTo avoid this issue when writing URLs in plaintext, I add a space at the end. > Check out https://example.com/thing https://example.com/thing . They've got... Let's say we were serious about solving this problem (without adopting a strategy like mine above). We would need a set of rules for plaintext-safe URLs. It would comprise: - An extension to the URL syntax to specify the subset of URLs that are plaintext safe. It might be as simple as a list of punctuation characters that cannot appear at the end of a URL (unless they are percent encoded). - Guidelines and test vectors for implementers of URL identification algorithms. - Guidelines for content authors. E.g., "The only characters that may immediately follow a URL are..." - A recommendation for web developers to ensure plaintext safefy when creating new URLs.
- fanf2 6y agoThere's already RFC 3986 appendix C https://tools.ietf.org/html/rfc3986#appendix-C https://tools.ietf.org/html/rfc3986#appendix-C but delimiting UTLs with <> has gone out of fashion, and sometimes is not supported. e.g. hacker news gets it wrong by counting the > as part of the URL even though it isn't a valid URL character.
- adontz 6y ago"Virgin Media’s Marketing Team" for sure, because it's their responsibility to test if their message works. There always will be some buggy software around. It could be feature phone, iOS, Windows Phone (devices are still alive), some tablet with SIM or whatever. It is "Marketing Team"'s responsibility to test if their message can actually reach their customers. Everything should be tested. Always.
- lizardmancan 6y agothe browser should also attempt to help the user find the desired page (within reason)
- whatnidnogg 6y agoyeah that's a good question yo
- deleted 6y ago[deleted]