Skip to content

Additionals: Added maxsize plugin #1512

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

twolfson
Copy link

@twolfson twolfson commented Jul 8, 2015

We recently created a maxsize plugin to detect that a file is too large before submission. Based off of #450 and #1111, it looks like other people would like it as well. In this PR:

  • Added maxsize plugin into src/additional

Missing:

We didn't add any tests as there are no tests for the only other FileList based plugin (accept.js). I am assuming that the reason for this is we cannot programmatically tell a browser where to get our file uploads from.

@twolfson twolfson force-pushed the dev/add.max.size.sqwished branch from eaca996 to e2ea371 Compare July 8, 2015 22:28
@jzaefferer
Copy link
Collaborator

Thank you for the contribution. This looks like a good start, but very much needs tests. There is an open PR that added tests for the accept method (#1373) and one more that further extends the method (#1441). Both need some rebasing or other fixes to get merged. Could I interest you in that? If so, start with the accept PRs (rebase and whatever else is needed), then rebase this PR on top and share the testing infrastructure (the acceptFileDummyInput function).

@twolfson
Copy link
Author

imo, per-computer filetype validation isn't too trustworthy as it can change a lot from computer to computer (e.g. we have seen .pdf with the type of application/download, www/unknown, application/x-pdf). As a result, I would prefer to stay away from #1441 and its edge cases.

Is there anything that needs to be done in #1373 aside from a squash/rebase?

@jzaefferer
Copy link
Collaborator

No, I think that's all there is to it.

@twolfson
Copy link
Author

Is there any reason why I should do it over you? I am not quite sure I follow the problem =/ The attribution should still be preserved -- here is an example in jscs: jscs-dev/node-jscs@18b4ffc

@twolfson
Copy link
Author

If you are unfamiliar with how to grab commits from a PR outside of GitHub, here is a gist describing the details:

https://gist.github.com/piscisaureus/3342247

@jzaefferer
Copy link
Collaborator

The problem are the 7 commits on that PR, of which at least three produce conflicts during a rebase. I figured you could help resolve those, since you'd likely end up integrating some of those changes into your own PR anyway.

@twolfson
Copy link
Author

Taking a shot at getting #1373 back on its feet

staabm pushed a commit that referenced this pull request Nov 26, 2015
This adds support for types like "application/epub+zip"
which contain regex meta characters.

Fixes #1243, #1258. Closes #1531, #1373. Refs #1512.
@ghost
Copy link

ghost commented Sep 22, 2016

@jzaefferer @twolfson Please look at #6834.

@twolfson
Copy link
Author

This PR was opened over a year ago, I no longer work at the organization I started it from, and I no longer have time to contribute to this PR. Closing this PR -- someone can pull over the changes into another PR if they want them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy