cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Using cocoon: source in <xsl:import>s
Date Thu, 21 Aug 2003 12:41:18 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Vadim Gritsenko wrote:
>>>  
>>>
>>>> Phil Shafer wrote:
>>>>
>>>>  
>>>>
>>>>> Vadim Gritsenko writes:
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> Try the suggestion above.
>>>>>>
>>>>> Will do. Thanks for the help. Is there a PR open for this? Should
>>>>> I open one?
>>>>>
>>>> I think there is no bug open for this. Also, I'd ping Carsten to 
>>>> hear his opinion. Carsten?
>>>>
>>>> PS Thread: http://marc.theaimsgroup.com/?t=106067513100007&r=1&w=2
>>>>  
>>>
>>>
>>> Pong.
>>>
>>> I think this is something the internal processing should handle, which
>>> means, if the reader sets such a header it should simply be ignored
>>> instead of being passed on.
>>> Now, I guess this is very easy as we could create a response wrapper
>>> for internal requests (we already have a request wrapper) and filter
>>> the headers.
>>>
>>
>> This reminds me some random thoughts I had with Gianugo around a beer 
>> last february : we were discussing the ability for internal sources 
>> to set response headers and came to the conclusion that there was no 
>> yes/no rule for all headers, and that the behaviour was dependent on 
>> the header type.
>
>
>
> Actually it depends not on header type alone but on usage of the 
> resource. If it is aggregated to be part of the output - then I agree 
> with some of your thoughts below. But if it is, say, called from the 
> flow - none of headers should make it into the actual response. 
> Another example I could make is authentication action which 
> authenticates against cocoon:/ resource. No response headers of 
> internal request should affect actual login page response.


Mmmh... yep, it seems this problems is tricky ;-)

So propagation of headers depends on the fact that the request 
"participates" to the building of the final response, meaning its result 
can be found in some way to what is sent to the browser, e.g. through 
aggregation, xinclude, internal redirects.

How can we determine this ? I'm not sure this can be determined 
automatically. For example, the headers set by the "src" of 
FileGenerator can be propagated, while those of the "src" of 
TraxTransformer should not.

And leaving this decision to the caller of SourceResolver.resolve() 
doesn't seem to be the solution, as it opens the doors to both omissions 
and abuses.

Any idea ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message