Allow adding an extension to a shortened link #27

Closed
opened 2019-12-13 15:00:32 +01:00 by minnozz · 1 comment
Collaborator

This allows some (IRC) clients to detect the link as, for example, a link to an image, and showing additional UI options to expand the image inline.

  • Current link: https://hashru.link/PVwZ
  • Proposed alternative link: https://hashru.link/PVwZ.gif
  • Workaround that has the same effect in my IRC client: https://hashru.link/PVwZ#.gif

Questions:

  • Should the server do something with the provided extension, like changing the Content-Type response header?
  • Should the shortened link with extension (autodetected from the content) be returned in addition to the link without extension, or should the user add it themselves?
This allows some (IRC) clients to detect the link as, for example, a link to an image, and showing additional UI options to expand the image inline. - Current link: `https://hashru.link/PVwZ` - Proposed alternative link: `https://hashru.link/PVwZ.gif` - Workaround that has the same effect in my IRC client: `https://hashru.link/PVwZ#.gif` Questions: - Should the server do something with the provided extension, like changing the `Content-Type` response header? - Should the shortened link with extension (autodetected from the content) be returned in addition to the link without extension, or should the user add it themselves?
Owner

First of all, I kinda think that IRC clients should first do a HEAD request, before inferring anything about the URL. However, if they don't, and we can fix it, we really should.

Questions:

  • Should the server do something with the provided extension, like changing the Content-Type response header?

I don't think it should, because it feel that it could allow the crafting of very malicious links. On the other hand, if we don't do this, users can upload .jpg files that are really of different file types. Which behavior is better?

  • Should the shortened link with extension (autodetected from the content) be returned in addition to the link without extension, or should the user add it themselves?

Looking at 0x0.st, they have the server add the extension to the URL. I think we should also do this. Moreover, deleting information is easier than adding it.

First of all, I kinda think that IRC clients should first do a `HEAD` request, before inferring anything about the URL. However, if they don't, and we can fix it, we really should. > Questions: > - Should the server do something with the provided extension, like changing the `Content-Type` response header? I don't think it should, because it feel that it could allow the crafting of very malicious links. On the other hand, if we don't do this, users can upload `.jpg` files that are really of different file types. Which behavior is better? > - Should the shortened link with extension (autodetected from the content) be returned in addition to the link without extension, or should the user add it themselves? Looking at `0x0.st`, they have the server add the extension to the URL. I think we should also do this. Moreover, deleting information is easier than adding it.
electricdusk added the
feature
label 2019-12-13 16:58:47 +01:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: electricdusk/rushlink#27
No description provided.