Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of lpb+cocoon@focalpoint.com
 designates 66.237.148.186 as permitted sender)
Date: Wed, 27 Oct 2004 11:04:23 -0500 (CDT)
From: Luigi Bai <lpb+cocoon@focalpoint.com>
To: dev@cocoon.apache.org
Subject: Re: When to set mime-type
In-Reply-To: <417FC2B3.6050403@hippo.nl>
Message-ID: <Pine.LNX.4.61.0410271055250.15169@nexxus.focalpoint.com>
References: <20041026170705.84208.qmail@minotaur.apache.org>
 <417E8954.70600@hippo.nl>
 <417E90F2.605@reverycodes.com> <417F8BA3.9090805@hippo.nl>
 <Pine.LNX.4.61.0410270909430.15169@nexxus.focalpoint.com>
 <417FB3B6.80709@hippo.nl>
 <Pine.LNX.4.61.0410271016300.15169@nexxus.focalpoint.com>
 <417FC2B3.6050403@hippo.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Focal-Point-Software-Inc-MailScanner-Information: Please contact the ISP for
 more information
X-Focal-Point-Software-Inc-MailScanner: Found to be clean
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


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! :-) 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? 
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? I have to admit I have not tried that; the 
description of the workflow, and my admittedly cursory review of the code, 
discouraged me from that experiment.

Thanks;
Luigi

> --
> Unico
>
>