cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bai <>
Subject Re: When to set mime-type
Date Wed, 27 Oct 2004 15:23:08 GMT

On Wed, 27 Oct 2004, Unico Hommes wrote:

>> I would like to consider allowing the mime-type to be set during 
>> processing, perhaps even as late as after endDocument(). The reason for 
>> this is: I store images in XML documents as Base64 encoded data, and its 
>> element tag looks like this:
>> <image mime-type="image/png">Base64data</image>
>> In this way I can store any kind of image in my files, and it is extracted 
>> correctly (I have a Base64Serializer to stream it out). However, in order 
>> to correctly extract it, I have to know, in the sitemap, /a priori/, what 
>> the mime-type is. Which leads to ugly hacks such as: "You can only put PNG 
>> images in this document and JPG images in this document, so I know how to 
>> extract them", or perhaps the requester would have to know to ask for a 
>> particular mime-type. And adding support for a new image type (admittely 
>> this does not happen frequently!) means updating the sitemap and adding new 
>> "rules". If I could set the mime-type of the response at least after the 
>> pertinent startElement(), then I'd be fine. Of course, that would mean that 
>> the response couldn't start streaming until it was "complete" - in this 
>> case, setting the mime-type might be the last thing it needs before 
>> beginning the stream.
> Exactly. This is the problem with delaying the setting of the mime type. For 
> the general case we'd always have to buffer the whole response which isn't 
> practical.

Well, according to the Servlet spec, you really should set ContentType 
before beginning the output stream, especially if you're using a Writer 
and not an OutputStream (for charset to be handled correctly). So it seems 
orthogonal to buffering.

And Cocoon already has shouldSetContentLength(), which tells 
the pipeline that at least ContentLength happens later in the processing 
(and of course the output has to be buffered). If that is not set, the 
general case is to stream without contentLength.

I'd propose a shouldSetContentType(), which would be a special case (not 
the general case); it would tell the pipeline to wait to send output until 
the contentType is set. This may or may not cause buffering; indeed, in 
the use-case I described, nothing is sent to the output stream by the time 
the image content-type is known.

> What you could do instead is to manually set the response header in the 
> serializer and make sure the pipeline that processes the response has a large 
> enough buffer. You can set the outputBufferSize parameter either during the 
> pipe's configuration or using a sitemap parameter.

Is it true that setting response headers in the Serializer will be 
respected? It's not clear that's true in all cases - various Wrapped 
Responses throw that away. I think it should be more explicitly part of 
the workflow.


> --
> Unico

View raw message