Download button

[yannickfunk]

This PR persists the file extension into the database and adds a download button for direct file download

[matze]

The download feature is much appreciated but why the need for the database layout change? The whole thing could be a lot simpler by just fetching the raw data from the database and then appending the extension on the response as requested by the user. Similar to how the paste view highlights on demand.

[yannickfunk]

My problem was that I couldn't see a way to obtain the extension after the paste was created. Initially I thought it is as easy is getting the extension from Entry because Entry is a 1:1 mapping to the db content. But it appeared that Entry doesn't 1:1 reflect the db content because extension is not persisted.

Could you point me to an alternative way to obtain the extension when download()
https://github.com/yannickfunk/wastebin/blob/4e2b143e54af3138be0c839907ade805fed78d3f/src/rest.rs#L61
is called?

One dirty workaround I could imagine would be to use javascript to parse the extension from window.location.href and then pass it along with the id to the download/ route. But I don't like that

[matze]

Could you point me to an alternative way to obtain the extension

In the show handler id and ext are extracted from the final path segment. You could pass Key.ext (e.g using a getter) to the Paste template and reconstruct the filename there.

[yannickfunk]

Thanks a lot, totally missed that possibility. I added an updated version

[matze]

I suppose it should be possible to use Response::from_parts together with TypedHeaders to set the headers in a typesafe manner.

[yannickfunk]

Tried using TypedHeaders but it doesn't seem very ergonomic for Response building. Also, the header for which the Typing is the most important ContentDisposition does not support attachement (see https://docs.rs/headers/latest/src/headers/common/content_disposition.rs.html#56).

I now validated the inputs and put constraints on the static strings. Let me know if this ok.

[matze]

It's okay, I will think about it myself a bit. But strange that this old issue is still not resolved.

[matze]

I'll approve and run the workflow but please squash the commits, so git bisect becomes a bit easier to do in the future.

[yannickfunk]

As far as I know you can just choose the squash option when merging with the github ui. Let me know if it doesn't work

[matze]

I always assume people want to craft their own commits but since you are okay with squashing :-) anyhow, thanks!