- From: <kennykb@cobweb.crd.ge.com>
- Date: Tue, 23 Jan 96 21:25:58 -0500
- To: www-lib@w3.org
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 seem to be able to work around the problem by adding a line anchor->content_type = WWW_PLAINTEXT; before the while (ptr < stop) { 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. Right now, I'm just copying from the socket to a file, and then using HTLoadAbsolute to open the file with a `file:' URL. There *must* be a better way. -- 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 Tuesday, 23 January 1996 16:32:11 UTC