[Prev][Next][Index][Thread]
Re: Trouble with message/rfc822 parser
>I am aware that the the current implementation of MIME multipart parsing is
>not complete. One of the things missing is the inheritance of content types.
>However, it is not a good idea to asign the content type as you may get empty
>bodies and in that case the stream stack will still be created because it has
>a valid content type.
In the case of a CGI form processor, that's the right thing to do! An
empty part body within a multipart/form-data is a field in the form that
contains no data, and passing zero bytes of data down its stream stack is
exactly right. A totally empty message body is a form that was submitted
with no fields -- which is possible if all that the form contains is
checkboxes, and none of them is checked. There, too, I want to process
the transaction by passing zero bytes of data down the stream stack.
Really. 8-)
>Another problem - and this in fact affects the first problem as well - is that
>there is only one anchor representing all bodyparts of a multipart message.
>This means that you can not refer to one specific bodypart - this anchor will
>always refer to the whole lot.
Yeah, I noticed that. 8-) A CGI is always dealing with only a single request,
though. So in my case I don't really care what's in the anchor; I'm
always just processing the single request that I find on my standard input.
What I was planning to do is to direct the stream on a part-by-part basis.
Parts that are simple form fields will go to a presenter that will save them
in memory and make a callback. Parts that represent uploaded files will
go to HTSaveAndCallback. At the end of the multipart/form-data, I make a final
callback. I keep the data about the form content stashed behind the request
context.
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
kennykb@crd.ge.com P. O. Box 8, Room KWC273
Schenectady, New York 12301-0008 USA
References: