Re: Trouble with message/rfc822 parser
Subject: Re: Trouble with message/rfc822 parser
From: Henrik Frystyk Nielsen <email@example.com>
Date: Thu, 25 Jan 1996 17:20:38 -0500
From firstname.lastname@example.org Thu Jan 25 17: 20:47 1996
Reply-To: Henrik Frystyk Nielsen <email@example.com>
X-Mailer: exmh version 1.6.2 7/18/95
> I'm still struggling somewhat fruitlessly to hack up an RFC1867 parser
> using www-lib. My latest problem is that a part within a multipart/* message
> that has no Content-Type: line seems always to get a Content-Type of
> multipart/* and inherit its parent's boundary, which confuses the parser
> horribly. The default for MIME parts is supposed to be
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.
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. It may be a good idea to include a mean of
refering to each individual subtype, however, as there is no valid URL for a
multipart bodypart it will cause trouble if we make it a parent anchor even
though it does contains a full object. Maybe the solution would be to come up
with an _internal_ naming scheme for the individual body parts and then link
them together using the anchor links. Hmm - I don't have a good solution to
this problem right now. I hope that this may help you to get some more ideas...
> in the `parseheader' function in HTMIME.c. I'm not sure, though, what
> the implications might be, since there are obviously a number of other
> places that call HTMIME.c. Is there a better way to handle the
> Also, can someone advise me on an appropriate code fragment to launch
> the converter? I'm running in a CGI environment; that is, filedescriptor
> zero is a socket to the client, from which I'm supposed to read the form
> data, and the environment variable CONTENT_LENGTH contains the number of
> bytes of data. I thought of using HTLoadSocket, but it
> doesn't seem to have any way to constrain the
> amount of data to read.
The way to do this is to return HT_LOADED from _your_ stream when you have
read the number of bytes that you expect. Then this will be passed back to the
socket read loop which will then terminate. You can see an example of this in
the HTMIME.c module where we in order to support persistent connections - we
return HT_LOADED when we have read content-length bytes.
Henrik Frystyk Nielsen, <firstname.lastname@example.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA