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