Revive about connect-multiparty HOT 17 CLOSED

Sure sounds fine. May I add you as a maintainer?

from connect-multiparty.

If you'd like, but I'll probably only do bug fixes and docs because I don't use multipart myself

from connect-multiparty.

also, don't use connect.limit() and don't depend on connect. just pass the options to the multiparty constructor.

from connect-multiparty.

what about utils.hasBody and utils.mime ? can I delete those checks?

from connect-multiparty.

it's up to you. those are one liners you can probably just incorporate into multiparty.

from connect-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

from connect-multiparty.

@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.

from connect-multiparty.

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.

from connect-multiparty.

Awesome! I'll look forward, then, to switching to your module here for my multipart needs :)

from connect-multiparty.

@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)

from connect-multiparty.

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.

from connect-multiparty.

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.

from connect-multiparty.

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

from connect-multiparty.

And in a separate AJAX request, what do you mean exactly. base64 encoded files?

from connect-multiparty.

nope, just directly upload the file in binary using xhr2. doesn't support < ie10 though, so you have to progressively enhance or something.

from connect-multiparty.

Oh, yeah, in a perfect world :P... 95% of our traffic is IE.... translation: 95% of our revenue is IE. Darn old ladies!

from connect-multiparty.

lol yeah. my site targets tech savvy people so i don't bother with < ie9.

from connect-multiparty.