Allow IO when unrendering content types

[fizruk]

This makes path to multipart/form-data content type, as mentioned in #133 (comment).

[jkarni]

Is the reason we're keeping the Maybe that we want to be able to not do IO?

[soenkehahn]

@fizruk: This PR is a bit old and stale. Should probably be rebased on current master.

Also I'm not clear on the motivation. Was this to support file-uploads?

[jkarni]

Also I'm not clear on the motivation. Was this to support file-uploads?

Yes.

I think this is still the right approach for that, especially since I think it's easier to do with recent changes. I'll take a look at this PR today, and try to rebase it.

[jkarni]

Done. Tests pass and we no longer need unsafeInterleaveIO. That said, I think this needs a more precise set of tests about the functionality in servant-server (i.e., when the file is written, what errors are thrown if that fails, etc.). And the easiest way of writing those tests, to my mind, is writing the multipart content-type. So at the risk of scope creep, I'd wait on merging this.

[jkarni]

Taking a further look, it seems like it makes the most sense to keep the new MultiPartFormData combinator as a separate package, since the most natural way to define the instances is to use wai-extra, which is not a dependency I'm happy with servant having.

Another point to note is that I don't immediately see a nice way of having configurable options - e.g. file size limits. If we make this not specific to MultiPartFormData - e.g., if we have the maximum request body size in the Context - it would be nicer.

For now I'm going to use the default configuration options.

[jkarni]

For reasons mentioned in #133, I'm in favor of closing this. @fizruk agreed?

[phadej]

ping @fizruk, can this be closed?

[phadej]

Closing this.