cocoon-dev mailing list archives

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

> 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.

Huh? Probably we mean the same thing. In an http response, header come 
before body, otherwise its not a valid http response. With "buffering" I 
mean the process of stalling the streaming of the response body for a 
specified amount of bytes in order to allow modification of the response 
headers. Be that by physically setting an output buffer size in the 
Servlet API or brewing up something external to it. So one has a lot to 
do with the other.

> 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.

shouldSetContentLength doesn't tell the pipeline that content length 
happens later in the pipeline, it tells the pipeline it ought to do 
whatever it can to determine the content length. It happens to do that 
by buffering the output.

Anyway, I think content length is a special case since there is no 
general mechanism - like there is with mime-type - to determine it in 

> 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.

A Serializer will never deal with WrappedEnvironments AFAICS. Internal 
xml pipeline processing is pipeline minus Serializer.


View raw message