I've put up the code I mentioned for email-sending and a proxy server at https://github.com/LiberalArtist/multipart-writing-examples As noted, these are not general-purpose solutions to either of those problems—I know of a bunch of cases I don't cover, and I basically only have to use these with trusted input—so caveat utor! But hopefully they're useful. I'd be very happy to contribute to this effort, as well: a proper multipart writing library would go a long way to getting some of the little bits of code I've produced into good enough shape to post as a package, enough so that I've thought about tackling it myself.
On Tue, Jan 29, 2019 at 8:06 AM Christopher Lemmer Webber < cweb...@dustycloud.org> wrote: > I see... yeah, I thought about going this route but the reason it didn't > seem particularly "robust" to me is that I would have to read the entire > object into memory at once before passing it in as bytes. IMO it would > be better to have the option to provide ports with file data so the data > could be streamed in without reading the whole data into memory. > This is one of the things you'd definitely want in a library that I haven't dealt with, because in all of my cases I already have all the data in memory anyway. However that would, I still think, require being able to access the > http-conn struct accessors at the very least. I guess I would think about the code to do the writing separately from the specific target you would be writing to, though certainly you would want a good story for how to use it with the existing net libraries. Maybe you've already seen this, but most of the functions in this family support supplying post data as a `data-procedure/c <https://docs.racket-lang.org/net/http-client.html#(def._((lib._net%2Fhttp-client..rkt)._data-procedure%2Fc))>`, which lets you stream using chunked content transfer encoding. I think the most explicit documentation for that is under `http-conn-send! <https://docs.racket-lang.org/net/http-client.html#%28def._%28%28lib._net%2Fhttp-client..rkt%29._http-conn-send%21%29%29>`. On Tue, Jan 29, 2019 at 3:22 PM George Neuner <gneun...@comcast.net> wrote: > Multipart HTTP is similar but not exactly the same as MIME. > … > Multipart HTTP is simpler - AFAIK, it does not support recursive parts. I believe `multipart/form-data` is a restricted subset of MIME: at least, RFC 7578 <https://tools.ietf.org/html/rfc7578#section-4> says that "The media type multipart/form-data follows the model of multipart MIME data streams as specified in Section 5.1 of RFC 2046; changes are noted in this document." I hope that a single writing library would be able to handle both `multipart/form-data` and MIME for email, but some of the restrictions on `multipart/form-data` have implications for the design of a writer. In particular, in an email context, you might decide that it's up to the library whether to use a Content-Transfer-Encoding: an implementation could then decide to put everything in quoted-printable encoding so that it could reliably use a boundary containing, say, "=_", which can never appear in quoted-printable-encoded data. However, this strategy doesn't work for `multipart/form-data`, because RFC 7578 §4.7 <https://tools.ietf.org/html/rfc7578#section-4.7> says that senders "SHOULD NOT" use Content-Transfer-Encoding (even though the RFC itself uses quoted-printable encoding in an example in section 4.5 <https://tools.ietf.org/html/rfc7578#section-4.5>)—I learned this after sending quoted-printable encoding provoked a null pointer error in a real server I was talking to. Of course, you can also send normal, email-style MIME over HTTP by using an appropriate content type header (`multipart/alternative`, `multipart/mixed`, etc.), just as you can send `application/json`. -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
