You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per our brief discussion on Twitter @ixti, here is an issue to collect together our progress on a server-side parser for this multipart form-data library. I'll gladly help with this, time allowing.
This will also resolve the following associated issues:
I have functioning server-side parsing code I'm using myself, which is based on danabr/multipart-parser. Rather than just forking that repository I figured we could absorb and continue to maintain whatever we use, as that code is released under MIT.
Are there any objections to that? The last commit on that repository was 3 years back, and the code is all ruby-native.
I just wanted to note that I tried danabr/multipart-parser, and surprisingly I found it to be significantly slower than Rack's multipart parser. I generated a multipart body from a 25MB file, and parsed it with both multipart-parser and Rack's multipart parser, and Rack took about 4s whereas multipart-parser took around 35s.
It's not that I needed it or anything, I was just wondering what was the performance comparison between the two.
Per our brief discussion on Twitter @ixti, here is an issue to collect together our progress on a server-side parser for this multipart form-data library. I'll gladly help with this, time allowing.
This will also resolve the following associated issues:
I have functioning server-side parsing code I'm using myself, which is based on danabr/multipart-parser. Rather than just forking that repository I figured we could absorb and continue to maintain whatever we use, as that code is released under MIT.
Are there any objections to that? The last commit on that repository was 3 years back, and the code is all ruby-native.
/cc: @tarcieri, @kenichi
The text was updated successfully, but these errors were encountered: