A <textarea> is not posted as a file, so that may be the problem.
I suggest adding a third possible POST field called paste for POSTing a regular form field that is not a file.
The POST data is parsed here: https://gitea.hashru.nl/dsprenkels/rushlink/src/branch/master/handlers.go#L212
The method used is https://golang.org/pkg/net/http/#Request.FormFile
A `<textarea>` is not posted as a file, so that may be the problem.
I suggest adding a third possible POST field called `paste` for POSTing a regular form field that is not a file.
minnozz
was assigned by electricdusk2020-04-03 12:07:30 +02:00
PasteTypePaste: currently unused; seems to fit the definition of this feature
Open questions:
Which form field name should we use?
Suggestions: paste=, content=, text=, data=, string=, body=
Should we autodetect the content type of the paste the same way as with file=? Or should it always be text/plain?
Where should the content be stored: in the database or in a file?
We could even define a cutoff below which the content is stored in the database, and above which it is stored in a file. This would increase complexity though; we would need two new paste types instead of one.
`internal/db/paste.go` defines 3 paste types:
- `PasteTypeRedirect`: used for `shorten=`
- `PasteTypeFileUpload`: used for `file=`
- `PasteTypePaste`: currently unused; seems to fit the definition of this feature
Open questions:
- Which form field name should we use?\
Suggestions: `paste=`, `content=`, `text=`, `data=`, `string=`, `body=`
- Should we autodetect the content type of the paste the same way as with `file=`? Or should it always be `text/plain`?
- Where should the content be stored: in the database or in a file?\
We could even define a cutoff below which the content is stored in the database, and above which it is stored in a file. This would increase complexity though; we would need two new paste types instead of one.
I forgot that I had introduced a PasteTypePaste in the past. We should probably use that type, yeah.
I think text= or paste= might be the best field type name, because I think it would fit best into the curl command:
curl -F'text=Hello World!' https://hashru.link
# or
curl -F'paste=Hello World!' https://hashru.link
With respect to saving the content in the database, I think we should be careful with storing big chunks of data into the database. Consider that the admin might choose to put the database on an SSD for performance, and the files on a hard disk, we would not want the database file to grow too quickly. I would always restrict a paste stored in the database to a couple of kilobytes.
I personally feel like it could be best to just always store it to disk. This is also easier for the sake of consistency. Later we could just store or cache all blobs with a small size (say <= 4KB) in the database.
I forgot that I had introduced a `PasteTypePaste` in the past. We should probably use that type, yeah.
I think `text=` or `paste=` might be the best field type name, because I think it would fit best into the curl command:
```shell
curl -F'text=Hello World!' https://hashru.link
# or
curl -F'paste=Hello World!' https://hashru.link
```
With respect to saving the content in the database, I think we should be careful with storing big chunks of data into the database. Consider that the admin might choose to put the database on an SSD for performance, and the files on a hard disk, we would not want the database file to grow too quickly. I would always restrict a paste stored in the database to a couple of kilobytes.
I personally feel like it could be best to just *always* store it to disk. This is also easier for the sake of consistency. Later we could just store or cache all blobs with a small size (say <= 4KB) in the database.
I am unsure about the content type, but I lean towards forcing the content type to be text/plain.
I feel like if somebody pastes plain text into a <textarea>, then it always text/plain, expecially because we will likely not be adding an extension to the URL (I think we wouldn't want to risk guessing the wrong extension).
To achieve this, we should probably update db.NewFileUpload and add a contentType string argument, which will default to autodetect when the string is "".
I am unsure about the content type, but I lean towards forcing the content type to be `text/plain`.
I feel like if somebody pastes plain text into a `<textarea>`, then it always `text/plain`, expecially because we will likely not be adding an extension to the URL (I think we wouldn't want to risk guessing the wrong extension).
To achieve this, we should probably update [db.NewFileUpload](https://gitea.hashru.nl/dsprenkels/rushlink/src/branch/master/internal/db/fileupload.go#L111) and add a `contentType string` argument, which will default to autodetect when the string is `""`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I made a very hacky first attempt by editing the HTML of the main page in the inspector:
HTML:
Request:
Response:
The POST data is parsed here: https://gitea.hashru.nl/dsprenkels/rushlink/src/branch/master/handlers.go#L212
The method used is https://golang.org/pkg/net/http/#Request.FormFile
A
<textarea>is not posted as a file, so that may be the problem.I suggest adding a third possible POST field called
pastefor POSTing a regular form field that is not a file.internal/db/paste.godefines 3 paste types:PasteTypeRedirect: used forshorten=PasteTypeFileUpload: used forfile=PasteTypePaste: currently unused; seems to fit the definition of this featureOpen questions:
Suggestions:
paste=,content=,text=,data=,string=,body=file=? Or should it always betext/plain?We could even define a cutoff below which the content is stored in the database, and above which it is stored in a file. This would increase complexity though; we would need two new paste types instead of one.
I forgot that I had introduced a
PasteTypePastein the past. We should probably use that type, yeah.I think
text=orpaste=might be the best field type name, because I think it would fit best into the curl command:With respect to saving the content in the database, I think we should be careful with storing big chunks of data into the database. Consider that the admin might choose to put the database on an SSD for performance, and the files on a hard disk, we would not want the database file to grow too quickly. I would always restrict a paste stored in the database to a couple of kilobytes.
I personally feel like it could be best to just always store it to disk. This is also easier for the sake of consistency. Later we could just store or cache all blobs with a small size (say <= 4KB) in the database.
I am unsure about the content type, but I lean towards forcing the content type to be
text/plain.I feel like if somebody pastes plain text into a
<textarea>, then it alwaystext/plain, expecially because we will likely not be adding an extension to the URL (I think we wouldn't want to risk guessing the wrong extension).To achieve this, we should probably update db.NewFileUpload and add a
contentType stringargument, which will default to autodetect when the string is"".