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

Received on Thursday, 25 January 1996 17:54:17 UTC