Opened 13 years ago
Last modified 9 years ago
#508 accepted defect
You shouldn't have to upload a whole file to find out mediagoblin doesn't support it
| Reported by: | Christopher Allan Webber | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | programming | Keywords: | medium |
| Cc: | Stephen Compall | Parent Tickets: |
Description
I'm not really sure the best way to solve this, but we had a user who spent an hour attempting to upload a video only to get the message "sorry, but I don't support that file". I'm not sure what the best way to prevent this is... maybe we could pass up a list of file extensions we know we support? That's not really great either though considering the "catch all" or "catch conditionally" media type option we currently have. So, not really sure. But we should definitely deal with it.
Attachments (1)
Change History (13)
comment:1 by , 13 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
by , 13 years ago
| Attachment: | issue_508.patch added |
|---|
comment:2 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:3 by , 13 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:4 by , 13 years ago
Displaying supported file types is a good first step. As I understand the WTForms validator it works only when it has received the whole shebang. Could this be resolved in a fancy AJAXY uploader? I imagine:
One selects a file, e.g. by drag and drop, enters title, metadata and hits submit.
- Only the Metadata and filename are submitted and checked for errors/supported file types. If that passes the validator, some JS could upload the actual file, with a fancy progress bar showing the status.
A plain non-JS fallback mechanism could still require a full-file upload to determine if a file is valid.
comment:5 by , 12 years ago
| Cc: | added |
|---|
comment:6 by , 12 years ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → assigned |
comment:8 by , 12 years ago
It's also possible to rely RFC 2616 8.2.2 for this. This has the benefit of, say, preventing a 500MB upload should there be a error in the file contents near the beginning, rendering it unsupportable.
Firefox, Chromium, and I imagine many others don't follow the advice of 8.2.2. However, 10.4.14 implies that in this case, the server simply closing the connection would be okay.
comment:10 by , 12 years ago
| Status: | assigned → in_progress |
|---|
Hi! I'm moving this ticket from "assigned" to in_progress per our new workflow. Please update the ticket and let us know if you're still working on this. If you are, super great! If not, we'll remove the claim and move it back to "accepted" in a couple of weeks.
Thanks!
comment:11 by , 9 years ago
| Owner: | removed |
|---|---|
| Status: | in_progress → accepted |
comment:12 by , 9 years ago
| Keywords: | medium added |
|---|
I agree that listing supported extensions as a help text in the form would be the best way to prevent unnecessary uploading. Working on a patch now.