Allow adding an extension to a shortened link #27

New Issue

2019-12-13T15:00:32+01:00

minnozz commented

2019-12-13 15:00:32 +01:00

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?

electricdusk commented

2019-12-13 16:47:23 +01:00

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

electricdusk referenced this issue from a commit

2019-12-15 07:51:16 +01:00

Add extension to FileUpload request url Fixes #27

electricdusk closed this issue

2019-12-15 07:51:16 +01:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: electricdusk/rushlink#27