Revive
jonathanong opened this issue · comments
Since connect is going to eventually remove the multipart parser, do you want to revive this project? I would make it as simple as possible (save to file only) and direct users to use the parser directly if they enable any options like defer.
Sure sounds fine. May I add you as a maintainer?
If you'd like, but I'll probably only do bug fixes and docs because I don't use multipart myself
also, don't use connect.limit() and don't depend on connect. just pass the options to the multiparty constructor.
what about utils.hasBody and utils.mime ? can I delete those checks?
it's up to you. those are one liners you can probably just incorporate into multiparty.
I think utils.mime is only there because some clients send a content type header without a body. You might want to handle that differently
@superjoe30 I use the multipart module in connect, including simple "to files and forget" and streaming. If you are looking for assistance in reviving this module for a resurgence of people needing it, I'd certainly be happy to help.
thanks for the offer. I wrote most of the code a couple days ago but got interrupted - I'll try to remember to finish it up tonight.
Awesome! I'll look forward, then, to switching to your module here for my multipart needs :)
@jonathanong can the docs get a better explanation as to why it's being removed? The reason I'm asking is that I saw you're asking to "revive" it here.. So if it's not good enough to be in connect core, why would we want to use it stand-alone? Form file uploads is a huge part of web applications.
https://github.com/senchalabs/connect/wiki/Connect-3.0 doesn't state why (unless it's just the "security" risk stated and that's the only reason)
Oh and I'm not saying this library is bad, I'm just asking for more clarification, that's all :P I just looked into it because the deprecated warnings I'm getting after updating.
yes. basically if we only allow saving it to disk, people are going to 1) say it's a security risk (and say we should fix it) and 2) ask more features (which we will reject and people will get annoyed). it's easier just to remove it and not support it at all.
if you're doing anything nontrivial like reading the file streams directly, you'd want to use a multi parser directly. exposing the parser as a middleware just complicates things unnecessarily (especially since people will ask for a billion options).
i want this library to be revived so that people have multiple alternatives before we just remove it from connect.
you can edit the wiki yourself - if i can think of a better way to phrase it i will edit it. i didn't want it to be too verbose.
personally, i think multipart forms are a pain in the ass. just upload each file separately using AJAX. much easier to handle errors that way.
Yeah.. this also sounds like it should be a node feature in the http library for parsing query, post, and file params :(... In the perfect world... Siiigh
And in a separate AJAX request, what do you mean exactly. base64 encoded files?
nope, just directly upload the file in binary using xhr2. doesn't support < ie10 though, so you have to progressively enhance or something.
Oh, yeah, in a perfect world :P... 95% of our traffic is IE.... translation: 95% of our revenue is IE. Darn old ladies!
lol yeah. my site targets tech savvy people so i don't bother with < ie9.