Opened 10 years ago
Last modified 6 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.
Subtickets
Attachments (1)
Change History (13)
comment:1 Changed 10 years ago by
Owner: | set to bigjust |
---|---|
Status: | new → assigned |
Changed 10 years ago by
Attachment: | issue_508.patch added |
---|
comment:2 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 10 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:4 Changed 10 years ago by
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 Changed 9 years ago by
Cc: | Stephen Compall added |
---|
comment:6 Changed 9 years ago by
Owner: | changed from bigjust to pythonsnake |
---|---|
Status: | reopened → assigned |
comment:8 Changed 9 years ago by
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 Changed 9 years ago by
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 Changed 6 years ago by
Owner: | pythonsnake deleted |
---|---|
Status: | in_progress → accepted |
comment:12 Changed 6 years ago by
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.