Opened 12 years ago

Last modified 8 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)

issue_508.patch (1.8 KB ) - added by bigjust 12 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by bigjust, 12 years ago

Owner: set to bigjust
Status: newassigned

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.

by bigjust, 12 years ago

Attachment: issue_508.patch added

comment:2 by bigjust, 12 years ago

Resolution: fixed
Status: assignedclosed

comment:3 by bigjust, 12 years ago

Resolution: fixed
Status: closedreopened

comment:4 by spaetz, 12 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 Stephen Compall, 12 years ago

Cc: Stephen Compall added

comment:6 by pythonsnake, 12 years ago

Owner: changed from bigjust to pythonsnake
Status: reopenedassigned

comment:7 by Stephen Compall, 12 years ago

Related to #361.

comment:8 by Stephen Compall, 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:9 by pythonsnake, 12 years ago

This can be easily fixed with the new uploader I'm preparing. #486

comment:10 by Christopher Allan Webber, 12 years ago

Status: assignedin_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 Ben Sturmfels, 8 years ago

Owner: pythonsnake removed
Status: in_progressaccepted

comment:12 by Ben Sturmfels, 8 years ago

Keywords: medium added
Note: See TracTickets for help on using tickets.