3 ms·

I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better th

I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better than the other potential world we could lived in, where paths were a black box and every web server/framework invented their own structure for them.

hamburglar 5mo ago
My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.
- chrismorgan 5mo ago
  So long as it starts with a slash, go ahead! See how long it takes for someone to figure it out. It’s your website. Have fun with it! Do dumb things! :-)
- rkeene2 5mo ago
  Make sure you use URL-safe base64 or the portions that looks like a path can get mangled MII//epi Is converted to MII/epi
  - yencabulator 5mo ago
    That would be broken software. https://en.wikipedia.org/wiki/// https://en.wikipedia.org/wiki///
gritzko 5mo ago
In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle https://github.com/gritzko/beagle
- gritzko 5mo ago
  In fact, GitHub URIs are a good example of overusing paths: https://github.com/gritzko/beagle/blob/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md https://github.com/gritzko/beagle/blob/a7e17290a39250092055f... - user gritzko, - project beagle, - view blob, - commit a7e17290a39250092055fcda5ae7015868dabdb4, - file path VERBS.md ... all concatenated indiscriminately.
  - em-bee 5mo ago
    what would be a better way of doing that? i am not disagreeing, but i just can't think of any way to improve on this. put everything into the query part? i prefer to use the query only for optional arguments. in this example the blob argument is the only thing that doesn't fit in my opinion.
    - arjvik 5mo ago
      Every object in git (commit, tree, revision of a single file) has a hash that is guaranteed unique within a repository (otherwise many more things than a web UI would break) and likely also globally. I can understand wanting to isolate repositories to prevent hash collisions from causing problems, but within a repo everything has a universally unique ID. edit: for instance, that specific VERBS.md is represented by the blob 3b9a46854589abb305ea33360f6f6d8634649108.
      - em-bee 5mo ago
        that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed? https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md this should be sufficient to represent the file. "blob" is like a descriptor of the value that follows. it would be like doing this: https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae7015868dabdb4/file/VERBS.md this actually irks me every time i see it in a github url
        5mo ago

hamburglar 5mo ago

My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.

chrismorgan 5mo ago
So long as it starts with a slash, go ahead! See how long it takes for someone to figure it out. It’s your website. Have fun with it! Do dumb things! :-)
rkeene2 5mo ago
Make sure you use URL-safe base64 or the portions that looks like a path can get mangled MII//epi Is converted to MII/epi
- yencabulator 5mo ago
  That would be broken software. https://en.wikipedia.org/wiki/// https://en.wikipedia.org/wiki///

gritzko 5mo ago

In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle https://github.com/gritzko/beagle

gritzko 5mo ago
In fact, GitHub URIs are a good example of overusing paths: https://github.com/gritzko/beagle/blob/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md https://github.com/gritzko/beagle/blob/a7e17290a39250092055f... - user gritzko, - project beagle, - view blob, - commit a7e17290a39250092055fcda5ae7015868dabdb4, - file path VERBS.md ... all concatenated indiscriminately.
- em-bee 5mo ago
  what would be a better way of doing that? i am not disagreeing, but i just can't think of any way to improve on this. put everything into the query part? i prefer to use the query only for optional arguments. in this example the blob argument is the only thing that doesn't fit in my opinion.
  - arjvik 5mo ago
    Every object in git (commit, tree, revision of a single file) has a hash that is guaranteed unique within a repository (otherwise many more things than a web UI would break) and likely also globally. I can understand wanting to isolate repositories to prevent hash collisions from causing problems, but within a repo everything has a universally unique ID. edit: for instance, that specific VERBS.md is represented by the blob 3b9a46854589abb305ea33360f6f6d8634649108.
    - em-bee 5mo ago
      that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed? https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md this should be sufficient to represent the file. "blob" is like a descriptor of the value that follows. it would be like doing this: https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae7015868dabdb4/file/VERBS.md this actually irks me every time i see it in a github url
      - 5mo ago