4 ms·

Dang or mod please remove the "?xf26hn" text from the end of the URL so it is able to used to find the past posts by scripts: 145 points 1 year ago 105 comment

Dang or mod please remove the "?xf26hn" text from the end of the URL so it is able to used to find the past posts by scripts: 145 points 1 year ago 105 comments https://news.ycombinator.com/item?id=34482226 https://news.ycombinator.com/item?id=34482226 19 points 4 hours ago 5 comments https://news.ycombinator.com/item?id=40798224 https://news.ycombinator.com/item?id=40798224 Further suggest that HTML query params be disallowed in submissions; if URLs with params are relevant they can be added as comment(s).

dang 2y ago
I've taken it out in this case but we can't take them out in the general case because it sometimes changes what page gets displayed.
g15jv2dp 2y ago
How would you deal with <https://example.com/read_blog_post.php?id=1234 https://example.com/read_blog_post.php?id=1234>? The query param is absolutely necessary in that case.
- downvotetruth 2y ago
  https://example.com https://example.com would be the submission & https://example.com/read_blog_post.php?id=1234 https://example.com/read_blog_post.php?id=1234 an added comment or preferably the text (first comment) field. Yes, this would almost surely cause the 1 URL per year HN submission rule to be violated, but the expense is being unable to at least attempt to force a unique constraint on the URL as the query params are not required to be in order like ?id=123&comments=1 and ?comments=t&id=123 both being valid leading to the combinatorial growth in URLs pointing to the same content and hindering exact URL matching and filtering. Given that, search engines are also unlikely to favor that site structure when indexing over a scheme such as https://example.com/read_blog_post/id/1234 https://example.com/read_blog_post/id/1234 There is still the possibility if a host wanted to get around such a restriction the server could create virtual directories to allow the same reordering as the query params, but that could be detected and the site flagged if necessary.
  - calfuris 2y ago
    It seems like you're arguing on the wrong side of the is-ought divide. It doesn't matter how URLs should be structured, HN has to decide how to deal with how they are in fact structured by whatever site is being linked. HN exists to share articles, not to try to enforce a preferred URL structure, so making direct links impossible on sites that use a "non-preferred" structure is throwing the baby out with the bathwater. It would also be kind of hypocritical, considering that HN itself relies on query parameters to show everything but the front page.
    - downvotetruth 2y ago
      It does matter how URLs should be structured as that defines and constrains the text that is accepted by the designated input element otherwise without such any plain text translatable to a resource would be acceptable thus the need for rules to determine valid URLs. > HN exists to share articles Not to argue one way or another for that claim, but assuming it were true then enforcing a no query param constraint would allow greater visibility for the shared content as again it would prevent the specified case(s) of allowing it to get buried by submissions duplicating the link. Also, it seems pointless to go against the REST standard of using path params to identify a specific resource or resources while using query parameters to sort/filter those resources; disallowing direct linking to a filter does not make direct links to articles impossible. It is true that HN itself relies on query parameters to link resources that goes against the stated REST standard.
      - calfuris 2y ago
        You're talking about duplicate discussions, but if HN trims query parameters then how can it tell if a submission to a site that relies on query parameters is a duplicate? Every URL on such sites would become identical, making different pages appear to be duplicates. That would dramatically hurt the visibility of such sites, unless HN turned off the automatic duplicate prevention for those sites, in which case the situation would be worse than the current situation. The second half of your comment is again on the wrong side of the is/ought divide. Websites that (a) have content worth sharing and (b) use query parameters to identify a specific resource do in fact exist. The question is not whether those websites should be doing that, it is whether HN should make it impossible to link to specific resources on those websites or not.

dang 2y ago

I've taken it out in this case but we can't take them out in the general case because it sometimes changes what page gets displayed.

g15jv2dp 2y ago

How would you deal with <https://example.com/read_blog_post.php?id=1234 https://example.com/read_blog_post.php?id=1234>? The query param is absolutely necessary in that case.

downvotetruth 2y ago
https://example.com https://example.com would be the submission & https://example.com/read_blog_post.php?id=1234 https://example.com/read_blog_post.php?id=1234 an added comment or preferably the text (first comment) field. Yes, this would almost surely cause the 1 URL per year HN submission rule to be violated, but the expense is being unable to at least attempt to force a unique constraint on the URL as the query params are not required to be in order like ?id=123&comments=1 and ?comments=t&id=123 both being valid leading to the combinatorial growth in URLs pointing to the same content and hindering exact URL matching and filtering. Given that, search engines are also unlikely to favor that site structure when indexing over a scheme such as https://example.com/read_blog_post/id/1234 https://example.com/read_blog_post/id/1234 There is still the possibility if a host wanted to get around such a restriction the server could create virtual directories to allow the same reordering as the query params, but that could be detected and the site flagged if necessary.
- calfuris 2y ago
  It seems like you're arguing on the wrong side of the is-ought divide. It doesn't matter how URLs should be structured, HN has to decide how to deal with how they are in fact structured by whatever site is being linked. HN exists to share articles, not to try to enforce a preferred URL structure, so making direct links impossible on sites that use a "non-preferred" structure is throwing the baby out with the bathwater. It would also be kind of hypocritical, considering that HN itself relies on query parameters to show everything but the front page.
  - downvotetruth 2y ago
    It does matter how URLs should be structured as that defines and constrains the text that is accepted by the designated input element otherwise without such any plain text translatable to a resource would be acceptable thus the need for rules to determine valid URLs. > HN exists to share articles Not to argue one way or another for that claim, but assuming it were true then enforcing a no query param constraint would allow greater visibility for the shared content as again it would prevent the specified case(s) of allowing it to get buried by submissions duplicating the link. Also, it seems pointless to go against the REST standard of using path params to identify a specific resource or resources while using query parameters to sort/filter those resources; disallowing direct linking to a filter does not make direct links to articles impossible. It is true that HN itself relies on query parameters to link resources that goes against the stated REST standard.
    - calfuris 2y ago
      You're talking about duplicate discussions, but if HN trims query parameters then how can it tell if a submission to a site that relies on query parameters is a duplicate? Every URL on such sites would become identical, making different pages appear to be duplicates. That would dramatically hurt the visibility of such sites, unless HN turned off the automatic duplicate prevention for those sites, in which case the situation would be worse than the current situation. The second half of your comment is again on the wrong side of the is/ought divide. Websites that (a) have content worth sharing and (b) use query parameters to identify a specific resource do in fact exist. The question is not whether those websites should be doing that, it is whether HN should make it impossible to link to specific resources on those websites or not.