httprb / form_data Goto Github PK

RFC 7578 says that filename parameter is not required:

For form data that represents the content of a file, a name for the
file SHOULD be supplied as well, by using a "filename" parameter of
the Content-Disposition header field. The file name isn't mandatory
for cases where the file name isn't available or is meaningless or
private; this might result, for example, when selection or drag-and-
drop is used or when the form data content is streamed directly from
a device.

Currently filename parameter is always included if a part is file.

Can confirm if I using two form field, it works no problem.

Hi,

I encountered an incompatibility issue in the Twitter gem between http-form_data and simple_oauth. More explanation are given in this issue.

Basically here (http-form_data) and there (simple_oauth) the encoding is not done the same way.
http-form_data uses URI.encode_www_form which uses URI.encode_www_form_component which doesn't convert *, while simple_oauth encodes *. The twitter API requires * to be encoded as explained in this post.

I understand that it's not a bug in http-form_data per se, but would you be OK to merge a PR allowing users of the gem to override the method encoding data in HTTP::FormData::Urlencoded#initialize and provide their own? By default it'd obviously still be ::URI.encode_www_form so it'd be a transparent change.
If it sounds somewhat acceptable to you, I'd be glad to work on something and to submit a PR.

Thanks 🙂

I accidentally used the form_data gem instead of http-form_data. I’m suggest you yank all version of form_data, so others don’t make the same mistake.

From RFC 7578:

Each part MAY have an (optional) "Content-Type" header field, which
defaults to "text/plain". If the contents of a file are to be sent,
the file data SHOULD be labeled with an appropriate media type, if
known, or "application/octet-stream".

Setting Content-Type for non-file parts is not currently supported.

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:

• celluloid/reel#149
• kenichi/angelo#47

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

Duplicating the issue I opened on http (httprb/http#175), because it seems to be more relevant here:

Apologies if this already exists, but I haven't found any references to it.

Sometimes one needs to send data via multipart/related. This, so far, has been a huge pain in the ass, with almost every other ruby HTTP solution.

Comparatively, other libraries, such as Node.js' request make it downright simple. If we could get something similar to request's level of multipart/related support, it would be awesome. They not only solve the initial issue of crafting multiparts, but they go above and beyond and let you deal with some implementation caveats.

Thanks!

I've been seeing some issues with this gem in jruby, that led me to this snippet here, where I think that some encoding mis-handling might be happening, and wanted to open the discussion before a PR is submitted.

The snippet in question was (in my case) "shadowed" by IO.copy_stream, but the gist of it is:

• outbuf.to_s.replace("") will return an "UTF-8" string.
• @bufferis a binary string.
• outbuf << @buffer will not change the encoding in outbuf (it'll remain "UTF-8").
• @buffer.length != @buffer.bytesize

I'd like to propose the following changes:

• all strings (outbuf, @buffer) should be binary (current_io.read(length, @buffer)would anyways convert the buffer to binary if it were another encoding).
• switch to @buffer.bytesize;
• switch to use "".b for initialization (because String.new.encoding, String.new("").encoding...).

Hello,

I'm wondering about Ruby keyword arguments in form_data. Keyword arguments are a Ruby 2.0 feature. (Ruby 2.1 gave us "required keyword arguments". Source)

Which version introduced their usage?

I'm wondering because I am trying to make reel build on JRuby 1.7.x