Re: Trouble with message/rfc822 parser

kennykb@cobweb.crd.ge.com writes:
> 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
> text/plain;charset="us-ascii".

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
> problem?
> 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, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA