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 16:57:23 GMT
Luigi Bai wrote:

> On Wed, 27 Oct 2004, Unico Hommes wrote:
>> Luigi Bai wrote:
>>>> 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.
> Yes, we mean the same thing. I was just pointing out that in a 
> pipeline, it's not always the case that _anything_ has streamed out 
> (needs to be buffered) by the time the headers are all ready - even if 
> the headers are set in the Serializer. So, it's an observation about 
> the Cocoon workflow, not headers and buffering in general.
>>> 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.
> Well, there's only a "general mechanism" to determine mime-type in 
> advance if you require it to be set in advance. That's a circular 
> argument! :-) 

That's not what the argument was about though. The point is that there 
is no way to determine the content-length berforehand. In this way 
content lenght is different from mime-type.

> My point is that in a data-driven model, the pipeline may not know 
> until the Serializer has started processing the stream (and not just 
> at setup() but after startDocument()) what the characteristics of the 
> data are. Since the Response headers are supposed to reflect what the 
> data is, shouldn't it be possible for the data to influence what 
> headers are sent to represent it? 

OK. In some special cases, the data that flows through the pipeline 
determines the characteristics of the outputted data, ie. it is only 
available by actually processing the pipeline, and it cannot be 
determined beforehand. In this case you want a mechanism to set the 
mime-type during that processing stage. But such a mechanism exists in 
Cocoon, just not by interfacing with the ProcessingPipeline but by using 
the  Response object in the Serializer directly. I think the best way to 
solve this is using that.

> The Servlet spec, with all its redirects and includes, makes it 
> possible, although with many cautions about flushing etc.

>>> 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.
> I didn't know that. However: if the content is being "streamed" to the 
> client, at what point are the headers sent? Can it be said for certain 
> that a Serializer can set headers after startDocument(), and these 
> headers are sent to the client? 

Actually I think that in your case it is not a problem and you don't 
have bother with buffer size. You'll always know the mime-type before 
you start steaming because it is an attribute of the element enclosing 
the contents you are going to stream.


View raw message