Hi Dan, I looked into the upload issue recently as well, because I'd needed and was surprised to see it wasn't there.
The way Happstack deals with this is that they make the uploaded files part of the other params. I grew to like this model and it worked well, because if you think about it, it fits the way you would perceive web requests at an abstract level. We only see them as being separate because file uploads were sort of hacked-on after the fact in RFC1867. They are conceptually a detail of the application-layer transport (i.e. HTTP). We should ask ourselves what benefit a programmer would derive from making a distinction between <form> inputs that get dumped in the request body and the inputs that would normally be encoded in the URL, and thus requiring the programmer to look in two places for the request inputs.[1] If you wanted to distinguish between regular parameters and files, it may be better to do so at the type level.[2] Either way, the core of work that needs to be done is: 1. Look at the Content-Type header. if it is multipart/form-data or multipart/mixed then we continue to 2. 2. Create a attoparsec[3] that gets the file uploads from the request. Now if we decide to make something separate from the params, this is practically all we'd need. Two lines would be added to receiveRequest in Server.hs. If we want to go with the more elegant end-user model, we'd need to put in some code where the existing application/x-www-form-urlencoded stuff is in parseForm. But as it is, that code already looks at the Content-Type header to process the urlencoded stuff.[4] Another thing to consider is that this stuff has use beyond Snap. It's not like you only find MIME multipart in HTTP messages. Regardless of what the Snap guys decide we should do, let me know what you've been up to, what you've written so far. I've written a bunch of small RFC822 and RFC2045 token parsers. Not the whole spec. Just the generics you'd could re-use to parse stuff like the HTTP headers, the cookies, and the multipart params. Yea that was getting longwinded too. Tell me what you think. -Arthur [1] In fairness to Yesod, Rails does this too. But that doesn't mean it's right. I love my Rails fwenz but not everything they do is kosher. Especially those strange rites involving Celtic runestones. [2] That was something Happstack didn't do, and was something I was annoyed at them for not doing. But I will concede that this would be a lot more work, design-wise, and can be done after we actually implement file-upload. [3] Gregory's suggestion of writing an attoparsec to do the core of the work is a good idea. Writing an iteratee parser is too heavyweight. We'd end up rewriting an iteratee version of attoparsec. As it is, there is already code to turn an attoparsec into an efficient iteratee. Parsing from bytestrings is too low level. I tried this, and though it worked (i.e. I could see my uploaded files), I decided I did not want to submit it for consideration. [4] Btw, there isn't any mention of this in the RFC. This should have been obvious to me, because the "x-" prefix means that it was an extension added after-the-fact. How irritating. But it *is* in the W3C rec: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 We should start by doing what the rec says, and pick out all the multipart elements that have the subtype "form-data".
_______________________________________________ Snap mailing list [email protected] http://mailman-mail5.webfaction.com/listinfo/snap
