2 ms·

These URLs kill me, I share a lot of links and these branches use full commit strings (instead of just "default" or "stable" human readable) and the links it cr

These URLs kill me, I share a lot of links and these branches use full commit strings (instead of just "default" or "stable" human readable) and the links it creates to PRs includes the actual title (which I find I can delete manually, but this is the default behaviour). stable: https://kallithea-scm.org/repos/kallithea/files/7f3515800bd8e693de8383b52adf09254b4fc1e5/ https://kallithea-scm.org/repos/kallithea/files/7f3515800bd8... PR: https://kallithea-scm.org/repos/kallithea/pull-request https://kallithea-scm.org/repos/kallithea/pull-request -> https://kallithea-scm.org/repos/kallithea/pull-request/140/_/Incoming_changes_from_Andrew_used_on_https_//kallithea-scm.org/repos/ https://kallithea-scm.org/repos/kallithea/pull-request/140/_... (...which you can delete everything after /140/ and it works fine). Oy vey.

cazim 5y ago
>(...which you can delete everything after /140/ and it works fine). This is good pattern but not implemented correctly. It should rewrite to full correct url. It can be abuse like this: /140/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_...
- chrisshroba 5y ago
  That doesn't seem like a new problem to me - you can already give someone a link with extraneous info in it using query params and fragments: https://google.com?you_should_use_bing_instead https://google.com?you_should_use_bing_instead https://google.com#you_should_use_bing_instead https://google.com#you_should_use_bing_instead
  - julianlam 5y ago
    cazim's point was that the url path should still work but rewrite back to the correct canonical URL. Query strings and hashes are a little different, since those may contain information you might not want to scrub. "Vanity" paths in particular can be rewritten because you often have a "correct" value for a given route. e.g. https://community.nodebb.org/topic/180/who-is-using-nodebb https://community.nodebb.org/topic/180/who-is-using-nodebb You can rewrite the tail end of this URL to whatever you'd like but it will always redirect you back to the correct canonical slug.

cazim 5y ago

>(...which you can delete everything after /140/ and it works fine). This is good pattern but not implemented correctly. It should rewrite to full correct url. It can be abuse like this: /140/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_...

chrisshroba 5y ago
That doesn't seem like a new problem to me - you can already give someone a link with extraneous info in it using query params and fragments: https://google.com?you_should_use_bing_instead https://google.com?you_should_use_bing_instead https://google.com#you_should_use_bing_instead https://google.com#you_should_use_bing_instead
- julianlam 5y ago
  cazim's point was that the url path should still work but rewrite back to the correct canonical URL. Query strings and hashes are a little different, since those may contain information you might not want to scrub. "Vanity" paths in particular can be rewritten because you often have a "correct" value for a given route. e.g. https://community.nodebb.org/topic/180/who-is-using-nodebb https://community.nodebb.org/topic/180/who-is-using-nodebb You can rewrite the tail end of this URL to whatever you'd like but it will always redirect you back to the correct canonical slug.