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
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
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
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.
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
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
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?
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
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
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)
10 matches
Mail list logo