W3C home > Mailing lists > Public > www-lib@w3.org > July to September 1999

Re: handling multipart

From: Lex Spoon <lex@cc.gatech.edu>
Date: Fri, 23 Jul 1999 21:14:37 +0000 (GMT)
Message-Id: <199907232114.OAA33506@mailhub1.almaden.ibm.com>
To: www-lib@w3.org
Henrik Frystyk Nielsen <frystyk@w3.org> wrote:
> At 13:14 19/07/1999 -0400, Lex Spoon wrote:
> >From a look at the parser, at appears that all the parts of the body
> >are concatenated into the target stream.
> That is correct - each multipart entity is passed to a new MIME parser
> stream which then passes the data to the same target.
> A different mechanism would be to have a callback which called out from the
> MM stream whenever a new entity was found. This is easy to do with the
> existing stream: Just make the line where the stream stack is set up in the
> MM parser a condition of the mode of the stream. You can see an example of
> this in the HTMIME.c module where there are several variants of the MIME
> parser stream.
> The question is what the callback function should call. I would do that the
> same way as is done for the HTML parser and the HText interface, that is,
> where the stream stack currently is called in HTBound.c, change that so
> that instead the callback calls a registered handler with the stream object
> and the request object and expects a target in return. This target is then
> passed to the stream builder which then will build a MIME parser and hand
> the MIME body to the target stream.

Hmm.  How about passing something back to the Request manager between each part, and registering some handler directly with the request?  That way, you could handle individual requests differently.  At the least, when handling the body parts as they come in, it would be nice to be able to figure out which request they pertain to.

One way that might be nice all around would be to use the existing terminator, but to give it some new status.  It could be called precisely between the parts of the response, so that the handler could replace the target stream of the request if desired before the next stream stack is created.  Would doing this be as simple as adding another status message from the stream handler than HT_OK, and having the request managing code (wherever it is) notice this new status message and call the terminator when it sees it?

> >So what I'm really after is this: is there a way to set up a handler
> >that can respond to individual message parts as they arrive?  The
> >particular application I have in mind would treat the early parts
> >as initial versions of a web page, which then get automatically
> >updated over time.  But a general answer would be just fine.
> I don't remember - does this form for MM come as a special multipart
> mediatype, or is it multipart/related?

From a little web browsing, it appears to be multipart/x-mixed-replace.  Never before dealt with it myself, but it looks like just the ticket for my current situation.

Received on Friday, 23 July 1999 17:15:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:51 UTC