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.

Reply via email to