RE: Using cocoon: source in xsl:imports

2003-08-21 Thread Carsten Ziegeler
Sylvain Wallez wrote: 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

Re: Using cocoon: source in xsl:imports

2003-08-21 Thread Sylvain Wallez
Carsten Ziegeler wrote: Sylvain Wallez wrote: 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

Re: Using cocoon: source in xsl:imports

2003-08-21 Thread Vadim Gritsenko
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

Re: Using cocoon: source in xsl:imports

2003-08-21 Thread Sylvain Wallez
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.

Re: Using cocoon: source in xsl:imports

2003-08-21 Thread Vadim Gritsenko
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: snip/ 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

Re: Using cocoon: source in xsl:imports

2003-08-21 Thread Sylvain Wallez
Vadim Gritsenko wrote: Sylvain Wallez wrote: Vadim Gritsenko wrote: snip/ 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

RE: Using cocoon: source in xsl:imports

2003-08-20 Thread Carsten Ziegeler
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?

Re: Using cocoon: source in xsl:imports

2003-08-18 Thread Phil Shafer
Vadim Gritsenko writes: It's not concern of the resolver's user to fiddle with request / response. If change to be made, it should be done in cocoon source implementation. This sounds right. I think reader has a right to make this call unconditionally. If the resolver shouldn't fiddle with

Re: Using cocoon: source in xsl:imports

2003-08-18 Thread Vadim Gritsenko
Phil Shafer wrote: Vadim Gritsenko writes: It's not concern of the resolver's user to fiddle with request / response. If change to be made, it should be done in cocoon source implementation. This sounds right. I think reader has a right to make this call unconditionally. If the

Re: Using cocoon: source in xsl:imports

2003-08-14 Thread Vadim Gritsenko
Phil Shafer wrote: I'm seeing an error when I use xsl:imports containing cocoon: sources. During processing of the import sources, ResourceReader.processStream() calls: response.setHeader(Content-Length, Long.toString(contentLength)); But the response referenced is the _original_ (external)