You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by un...@apache.org on 2004/10/26 19:07:05 UTC
svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type
Author: unico
Date: Tue Oct 26 10:07:04 2004
New Revision: 55619
Modified:
cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml
cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap
Log:
remove testcase that no longer complies with expected behavior:
internal requests should not be able to alter response headers
as discussed in http://marc.theaimsgroup.com/?t=109783260100005&r=1&w=2
Modified: cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml (original)
+++ cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml Tue Oct 26 10:07:04 2004
@@ -57,7 +57,6 @@
<header name="Content-type" value="text/html"/>
</match>
</httpRequest>
-
<httpRequest href="${baseUrl}/test40.html" description="Check content-type">
<match>
<header name="Content-type" value="text/html"/>
@@ -68,18 +67,6 @@
<header name="Content-type" value="text/html"/>
</match>
</httpRequest>
-
- <httpRequest href="${baseUrl}/test50.html" description="Check content-type">
- <match>
- <header name="Content-type" value="text/html"/>
- </match>
- </httpRequest>
- <httpRequest href="${baseUrl}/test50.html" description="Check content-type (cached)">
- <match>
- <header name="Content-type" value="text/html"/>
- </match>
- </httpRequest>
-
<httpRequest href="${baseUrl}/test60.html" description="Check content-type">
<match>
<header name="Content-type" value="text/html"/>
Modified: cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml (original)
+++ cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml Tue Oct 26 10:07:04 2004
@@ -15,7 +15,7 @@
limitations under the License.
-->
-<!-- CVS $Id: explain-test.xml,v 1.3 2004/03/06 02:26:00 antonio Exp $ -->
+<!-- CVS $Id$ -->
<page>
<title>reader-mime-type test</title>
@@ -32,7 +32,6 @@
<li><link href="test20.html">test20.html</link></li>
<li><link href="test30">test30</link></li>
<li><link href="test40.html">test40.html</link></li>
- <li><link href="test50.html">test50.html</link></li>
<li><link href="test60.html">test60.html</link></li>
<li><link href="test70.html">test70.html</link></li>
</ul>
Modified: cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap (original)
+++ cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap Tue Oct 26 10:07:04 2004
@@ -31,9 +31,6 @@
<map:match pattern="test40.html">
<map:read src="cocoon:/test10.html"/>
</map:match>
- <map:match pattern="test50.html">
- <map:read src="cocoon:/test30"/>
- </map:match>
<map:match pattern="test60.html">
<map:read src="cocoon:/test10.html" mime-type="text/html"/>
</map:match>
Re: When to set mime-type
Posted by Luigi Bai <lp...@focalpoint.com>.
On Wed, 27 Oct 2004, Vadim Gritsenko wrote:
> Luigi Bai wrote:
>>
>> I would like to consider allowing the mime-type to be set during
>> processing, perhaps even as late as after endDocument().
>
> No, that's against "Cocoon Way". I'd even say, *all* headers should be set
> *before* startDocument, during pipeline assembly & setup stages. What's
> happening in ResourceReader currently WRT headers should be fixed - IIRC
> there is either Bugzilla entry for this or an email in archive.
>
> Vadim
>
Vadim, that approach doesn't allow the content to tell the container what
it is - is it reasonable to set ContentLength, Expires, etc. ahead of time
in all cases? I think you're describing a system which is inflexible, and
which precludes valid use cases. I'd prefer the "Cocoon Way" to be the
default way things operate, but that edge cases are even *possible*, not
precluded.
Luigi
Re: When to set mime-type
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Luigi Bai wrote:
>
> I would like to consider allowing the mime-type to be set during
> processing, perhaps even as late as after endDocument().
No, that's against "Cocoon Way". I'd even say, *all* headers should be set
*before* startDocument, during pipeline assembly & setup stages. What's
happening in ResourceReader currently WRT headers should be fixed - IIRC there
is either Bugzilla entry for this or an email in archive.
Vadim
Re: When to set mime-type
Posted by Luigi Bai <lp...@focalpoint.com>.
On Wed, 27 Oct 2004, Unico Hommes wrote:
> Luigi Bai wrote:
>
>>
>>
>>>> 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.
>
Not really different; a call to fstat() (File.length()?) can determine the
size of a file before it's streamed. I think the point is that sometimes
it's possible to know these things ahead of time and sometimes not. Right
now, it's not possible in Cocoon AFAIK to deal with the case when you
can't know this information up front.
And I'm not saying this would be something easy to change in Cocoon. From
just my cursory glance at the code (and I'm a newbie), it looks like many
places in the Pipeline Processing assume this information is available
after setup(). It would require more changes to be able to handle the
Pipeline being able to set information.
>> 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.
>
I will try that approach sometime soon. Unfortunately I am currently being
consumed by another part of my project!
Thanks;
Luigi
>
> --
> Unico
>
Re: When to set mime-type
Posted by Unico Hommes <un...@hippo.nl>.
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.
--
Unico
Re: When to set mime-type
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Luigi Bai wrote:
>
>
> On Wed, 27 Oct 2004, Unico Hommes wrote:
>
>> A Serializer will never deal with WrappedEnvironments AFAICS. Internal
>> xml pipeline processing is pipeline minus Serializer.
Hm, don't think so. Example:
<map:match pattern="dynamic.jpg">
<map:generate src="foo.svg"/>
<map:seialize type="svg2jpg"/>
</map:match>
<map:reader src="cocoon:/dynamic.jpg"/>
Vadim
Re: When to set mime-type
Posted by Luigi Bai <lp...@focalpoint.com>.
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
>
>
Re: When to set mime-type
Posted by Unico Hommes <un...@hippo.nl>.
Luigi Bai wrote:
>
>
> On Wed, 27 Oct 2004, Unico Hommes wrote:
>
>>>
>>> I would like to consider allowing the mime-type to be set during
>>> processing, perhaps even as late as after endDocument(). The reason
>>> for this is: I store images in XML documents as Base64 encoded data,
>>> and its element tag looks like this:
>>>
>>> <image mime-type="image/png">Base64data</image>
>>>
>>> In this way I can store any kind of image in my files, and it is
>>> extracted correctly (I have a Base64Serializer to stream it out).
>>> However, in order to correctly extract it, I have to know, in the
>>> sitemap, /a priori/, what the mime-type is. Which leads to ugly
>>> hacks such as: "You can only put PNG images in this document and JPG
>>> images in this document, so I know how to extract them", or perhaps
>>> the requester would have to know to ask for a particular mime-type.
>>> And adding support for a new image type (admittely this does not
>>> happen frequently!) means updating the sitemap and adding new
>>> "rules". If I could set the mime-type of the response at least after
>>> the pertinent startElement(), then I'd be fine. Of course, that
>>> would mean that the response couldn't start streaming until it was
>>> "complete" - in this case, setting the mime-type might be the last
>>> thing it needs before beginning the stream.
>>
>>
>>
>> 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.
> 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.
>
> 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.
--
Unico
Re: When to set mime-type
Posted by Luigi Bai <lp...@focalpoint.com>.
On Wed, 27 Oct 2004, Unico Hommes wrote:
>>
>> I would like to consider allowing the mime-type to be set during
>> processing, perhaps even as late as after endDocument(). The reason for
>> this is: I store images in XML documents as Base64 encoded data, and its
>> element tag looks like this:
>>
>> <image mime-type="image/png">Base64data</image>
>>
>> In this way I can store any kind of image in my files, and it is extracted
>> correctly (I have a Base64Serializer to stream it out). However, in order
>> to correctly extract it, I have to know, in the sitemap, /a priori/, what
>> the mime-type is. Which leads to ugly hacks such as: "You can only put PNG
>> images in this document and JPG images in this document, so I know how to
>> extract them", or perhaps the requester would have to know to ask for a
>> particular mime-type. And adding support for a new image type (admittely
>> this does not happen frequently!) means updating the sitemap and adding new
>> "rules". If I could set the mime-type of the response at least after the
>> pertinent startElement(), then I'd be fine. Of course, that would mean that
>> the response couldn't start streaming until it was "complete" - in this
>> case, setting the mime-type might be the last thing it needs before
>> beginning the stream.
>
>
> 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.
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.
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.
Luigi
> --
> Unico
>
>
Re: When to set mime-type
Posted by Unico Hommes <un...@hippo.nl>.
Luigi Bai wrote:
>
>
> On Wed, 27 Oct 2004, Unico Hommes wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Unico Hommes wrote:
>>>
>>>> Now only one release blocker remains: NPE in
>>>> AbstractEnvironment.release()
>>>
>>>
>>>
>>> No, not exactly. As I see it, ResourceReader should return Source's
>>> mimeType in this particular case, as per:
>>>
>>> public String getMimeType() {
>>> Context ctx = ObjectModelHelper.getContext(objectModel);
>>> if (ctx != null) {
>>> final String mimeType = ctx.getMimeType(source);
>>> if (mimeType != null) {
>>> return mimeType;
>>> }
>>> }
>>>
>>> return inputSource.getMimeType();
>>> }
>>>
>>> But in this case, it was not able to get mime type of the
>>> SitemapSource. SitemapSource, in its turn, was retrieving mimeType
>>> from the environment:
>>>
>>> 344: this.mimeType = this.environment.getContentType();
>>>
>>> But for some reason it is not there. I think that is the problem and
>>> it was a valid test case for this problem. Unless I am mistaken...
>>> If I'm not, we should revert the removal of test case.
>>
>>
>>
>> No don't say that! I thought we'd finally gotten rid it. :-(
>>
>> You are right though. My conclusion that the test case was no longer
>> valid was premature. It used to be that SitemapSource would just
>> return hard-coded text/xml as its mime type.
>>
>> Anyway, the problem appears to be that the mime-type is only set on
>> the environment by the processing pipeline during actual processing
>> whereas at the time Reader.getMimeType is called the pipeline has
>> only been setup and prepared.
>>
>> Now I am wondering whether we can move setting the mime-type from the
>> processing stage to the preparation stage. The reason it is currently
>> being done during processing is that in the case of the caching
>> pipeline the mime-type is held in the cached response and the
>> retrieval of the cached response is delayed until the processing
>> stage in order to optimize performance.
>>
>
> I would like to consider allowing the mime-type to be set during
> processing, perhaps even as late as after endDocument(). The reason
> for this is: I store images in XML documents as Base64 encoded data,
> and its element tag looks like this:
>
> <image mime-type="image/png">Base64data</image>
>
> In this way I can store any kind of image in my files, and it is
> extracted correctly (I have a Base64Serializer to stream it out).
> However, in order to correctly extract it, I have to know, in the
> sitemap, /a priori/, what the mime-type is. Which leads to ugly hacks
> such as: "You can only put PNG images in this document and JPG images
> in this document, so I know how to extract them", or perhaps the
> requester would have to know to ask for a particular mime-type. And
> adding support for a new image type (admittely this does not happen
> frequently!) means updating the sitemap and adding new "rules". If I
> could set the mime-type of the response at least after the pertinent
> startElement(), then I'd be fine. Of course, that would mean that the
> response couldn't start streaming until it was "complete" - in this
> case, setting the mime-type might be the last thing it needs before
> beginning the stream.
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.
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.
--
Unico
When to set mime-type (was: Re: svn commit: rev 55619 - in
cocoon/branches/BRANCH_2_1_X/src: test/anteater )webapp/samples/test/reader-mime-type
Posted by Luigi Bai <lp...@focalpoint.com>.
On Wed, 27 Oct 2004, Unico Hommes wrote:
> Vadim Gritsenko wrote:
>
>> Unico Hommes wrote:
>>
>>> Now only one release blocker remains: NPE in AbstractEnvironment.release()
>>
>>
>> No, not exactly. As I see it, ResourceReader should return Source's
>> mimeType in this particular case, as per:
>>
>> public String getMimeType() {
>> Context ctx = ObjectModelHelper.getContext(objectModel);
>> if (ctx != null) {
>> final String mimeType = ctx.getMimeType(source);
>> if (mimeType != null) {
>> return mimeType;
>> }
>> }
>>
>> return inputSource.getMimeType();
>> }
>>
>> But in this case, it was not able to get mime type of the SitemapSource.
>> SitemapSource, in its turn, was retrieving mimeType from the environment:
>>
>> 344: this.mimeType = this.environment.getContentType();
>>
>> But for some reason it is not there. I think that is the problem and it was
>> a valid test case for this problem. Unless I am mistaken... If I'm not, we
>> should revert the removal of test case.
>
>
> No don't say that! I thought we'd finally gotten rid it. :-(
>
> You are right though. My conclusion that the test case was no longer valid
> was premature. It used to be that SitemapSource would just return hard-coded
> text/xml as its mime type.
>
> Anyway, the problem appears to be that the mime-type is only set on the
> environment by the processing pipeline during actual processing whereas at
> the time Reader.getMimeType is called the pipeline has only been setup and
> prepared.
>
> Now I am wondering whether we can move setting the mime-type from the
> processing stage to the preparation stage. The reason it is currently being
> done during processing is that in the case of the caching pipeline the
> mime-type is held in the cached response and the retrieval of the cached
> response is delayed until the processing stage in order to optimize
> performance.
>
I would like to consider allowing the mime-type to be set during
processing, perhaps even as late as after endDocument(). The reason for
this is: I store images in XML documents as Base64 encoded data, and its
element tag looks like this:
<image mime-type="image/png">Base64data</image>
In this way I can store any kind of image in my files, and it is extracted
correctly (I have a Base64Serializer to stream it out). However, in order
to correctly extract it, I have to know, in the sitemap, /a priori/, what
the mime-type is. Which leads to ugly hacks such as: "You can only put PNG
images in this document and JPG images in this document, so I know how to
extract them", or perhaps the requester would have to know to ask for a
particular mime-type. And adding support for a new image type (admittely
this does not happen frequently!) means updating the sitemap and adding
new "rules". If I could set the mime-type of the response at least after
the pertinent startElement(), then I'd be fine. Of course, that would mean
that the response couldn't start streaming until it was "complete" - in
this case, setting the mime-type might be the last thing it needs before
beginning the stream.
What would this mean for caching? For me, it means the mime-type *cannot*
be part of the cache-key, since it cannot be known a priori. However, it
does have to be cached with the document.
> Is it really neccessary or desirable to cache the mime-type? What happens if
> the effective mime-type is from the one from the reader definition or the
> read node declaration (<map:reader class=".." mime-type="text/xml"/> or
> <map:read src="somewhere" mime-type="text/xml" />) From these examples it
> follows that the mime-type must be part of the cache-key because if you were
> to change it in any of the attributes above the previously cached contents
> should not be served.
>
> Btw. ResourceReader.getMimeType() method above looks a bit funny to me. The
> mime-type mapping from the context has priority over the mime-type of the
> individual source. Surely that should be the other way around?
>
> Comments?
>
> --
> Unico
>
>
Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src:
test/anteater webapp/samples/test/reader-mime-type
Posted by Unico Hommes <un...@hippo.nl>.
Vadim Gritsenko wrote:
> Unico Hommes wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Unico Hommes wrote:
>>>
>>>> Now only one release blocker remains: NPE in
>>>> AbstractEnvironment.release()
>>>
>>>
>>>
>>> No, not exactly. As I see it, ResourceReader should return Source's
>>> mimeType in this particular case, as per:
>>>
>>> public String getMimeType() {
>>> Context ctx = ObjectModelHelper.getContext(objectModel);
>>> if (ctx != null) {
>>> final String mimeType = ctx.getMimeType(source);
>>> if (mimeType != null) {
>>> return mimeType;
>>> }
>>> }
>>>
>>> return inputSource.getMimeType();
>>> }
>>>
>>> But in this case, it was not able to get mime type of the
>>> SitemapSource. SitemapSource, in its turn, was retrieving mimeType
>>> from the environment:
>>>
>>> 344: this.mimeType = this.environment.getContentType();
>>>
>>> But for some reason it is not there. I think that is the problem and
>>> it was a valid test case for this problem. Unless I am mistaken...
>>> If I'm not, we should revert the removal of test case.
>>
>>
>>
>>
>> No don't say that! I thought we'd finally gotten rid it. :-(
>
>
> Ooops. I'm sorry! :)
>
>
Never mind. It's not your fault ;-)
>> You are right though. My conclusion that the test case was no longer
>> valid was premature. It used to be that SitemapSource would just
>> return hard-coded text/xml as its mime type.
>>
>> Anyway, the problem appears to be that the mime-type is only set on
>> the environment by the processing pipeline during actual processing
>> whereas at the time Reader.getMimeType is called the pipeline has
>> only been setup and prepared.
>>
>> Now I am wondering whether we can move setting the mime-type from the
>> processing stage to the preparation stage.
>
>
> Probably we should, if possible.
I should be possible if the issue Luigi raised doesn't hold valid.
Should the data stream in the pipeline have any say over its own
characteristics? I am not sure. It would be a whole lot easier if we
would just mandate it. But then perhaps the Response.setHeader should
not even be available to sitemap components, or FOM even. Hmm.
>
>> The reason it is currently being done during processing is that in
>> the case of the caching pipeline the mime-type is held in the cached
>> response and the retrieval of the cached response is delayed until
>> the processing stage in order to optimize performance.
>
>
> If mime-type is always set during pipeline setup, it will be not
> necessary to store it in the cached response at all. Moreover, current
> situation is flawed anyway: what about all the other headers? They are
> all lost on second request. If all headers are set during pipeline
> setup, we won't have the issue.
>> Is it really neccessary or desirable to cache the mime-type?
>
>
> See above.
>
>
>> What happens if the effective mime-type is from the one from the
>> reader definition or the read node declaration (<map:reader
>> class=".." mime-type="text/xml"/> or <map:read src="somewhere"
>> mime-type="text/xml" />) From these examples it follows that the
>> mime-type must be part of the cache-key because if you were to change
>> it in any of the attributes above the previously cached contents
>> should not be served.
>
>
> Not if it set as described above.
>
>
>> Btw. ResourceReader.getMimeType() method above looks a bit funny to
>> me. The mime-type mapping from the context has priority over the
>> mime-type of the individual source. Surely that should be the other
>> way around?
>
>
> There were some changes around mime type handling in 2.2...
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10277
>
> ResourceReader implementation was not changed, though.
Yes, the conclusion at the end seems not to match the code in
ResourceReader.
--
Unico
Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src:
test/anteater webapp/samples/test/reader-mime-type
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Unico Hommes wrote:
> Vadim Gritsenko wrote:
>
>> Unico Hommes wrote:
>>
>>> Now only one release blocker remains: NPE in
>>> AbstractEnvironment.release()
>>
>>
>> No, not exactly. As I see it, ResourceReader should return Source's
>> mimeType in this particular case, as per:
>>
>> public String getMimeType() {
>> Context ctx = ObjectModelHelper.getContext(objectModel);
>> if (ctx != null) {
>> final String mimeType = ctx.getMimeType(source);
>> if (mimeType != null) {
>> return mimeType;
>> }
>> }
>>
>> return inputSource.getMimeType();
>> }
>>
>> But in this case, it was not able to get mime type of the
>> SitemapSource. SitemapSource, in its turn, was retrieving mimeType
>> from the environment:
>>
>> 344: this.mimeType = this.environment.getContentType();
>>
>> But for some reason it is not there. I think that is the problem and
>> it was a valid test case for this problem. Unless I am mistaken... If
>> I'm not, we should revert the removal of test case.
>
>
>
> No don't say that! I thought we'd finally gotten rid it. :-(
Ooops. I'm sorry! :)
> You are right though. My conclusion that the test case was no longer
> valid was premature. It used to be that SitemapSource would just return
> hard-coded text/xml as its mime type.
>
> Anyway, the problem appears to be that the mime-type is only set on the
> environment by the processing pipeline during actual processing whereas
> at the time Reader.getMimeType is called the pipeline has only been
> setup and prepared.
>
> Now I am wondering whether we can move setting the mime-type from the
> processing stage to the preparation stage.
Probably we should, if possible.
> The reason it is currently
> being done during processing is that in the case of the caching pipeline
> the mime-type is held in the cached response and the retrieval of the
> cached response is delayed until the processing stage in order to
> optimize performance.
If mime-type is always set during pipeline setup, it will be not necessary to
store it in the cached response at all. Moreover, current situation is flawed
anyway: what about all the other headers? They are all lost on second request.
If all headers are set during pipeline setup, we won't have the issue.
> Is it really neccessary or desirable to cache the mime-type?
See above.
> What
> happens if the effective mime-type is from the one from the reader
> definition or the read node declaration (<map:reader class=".."
> mime-type="text/xml"/> or <map:read src="somewhere" mime-type="text/xml"
> />) From these examples it follows that the mime-type must be part of
> the cache-key because if you were to change it in any of the attributes
> above the previously cached contents should not be served.
Not if it set as described above.
> Btw. ResourceReader.getMimeType() method above looks a bit funny to me.
> The mime-type mapping from the context has priority over the mime-type
> of the individual source. Surely that should be the other way around?
There were some changes around mime type handling in 2.2...
http://issues.apache.org/bugzilla/show_bug.cgi?id=10277
ResourceReader implementation was not changed, though.
Vadim
Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src:
test/anteater webapp/samples/test/reader-mime-type
Posted by Unico Hommes <un...@hippo.nl>.
Vadim Gritsenko wrote:
> Unico Hommes wrote:
>
>> Now only one release blocker remains: NPE in
>> AbstractEnvironment.release()
>
>
> No, not exactly. As I see it, ResourceReader should return Source's
> mimeType in this particular case, as per:
>
> public String getMimeType() {
> Context ctx = ObjectModelHelper.getContext(objectModel);
> if (ctx != null) {
> final String mimeType = ctx.getMimeType(source);
> if (mimeType != null) {
> return mimeType;
> }
> }
>
> return inputSource.getMimeType();
> }
>
> But in this case, it was not able to get mime type of the
> SitemapSource. SitemapSource, in its turn, was retrieving mimeType
> from the environment:
>
> 344: this.mimeType = this.environment.getContentType();
>
> But for some reason it is not there. I think that is the problem and
> it was a valid test case for this problem. Unless I am mistaken... If
> I'm not, we should revert the removal of test case.
No don't say that! I thought we'd finally gotten rid it. :-(
You are right though. My conclusion that the test case was no longer
valid was premature. It used to be that SitemapSource would just return
hard-coded text/xml as its mime type.
Anyway, the problem appears to be that the mime-type is only set on the
environment by the processing pipeline during actual processing whereas
at the time Reader.getMimeType is called the pipeline has only been
setup and prepared.
Now I am wondering whether we can move setting the mime-type from the
processing stage to the preparation stage. The reason it is currently
being done during processing is that in the case of the caching pipeline
the mime-type is held in the cached response and the retrieval of the
cached response is delayed until the processing stage in order to
optimize performance.
Is it really neccessary or desirable to cache the mime-type? What
happens if the effective mime-type is from the one from the reader
definition or the read node declaration (<map:reader class=".."
mime-type="text/xml"/> or <map:read src="somewhere" mime-type="text/xml"
/>) From these examples it follows that the mime-type must be part of
the cache-key because if you were to change it in any of the attributes
above the previously cached contents should not be served.
Btw. ResourceReader.getMimeType() method above looks a bit funny to me.
The mime-type mapping from the context has priority over the mime-type
of the individual source. Surely that should be the other way around?
Comments?
--
Unico
Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src:
test/anteater webapp/samples/test/reader-mime-type
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Unico Hommes wrote:
> Now only one release blocker remains: NPE in AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's mimeType in
this particular case, as per:
public String getMimeType() {
Context ctx = ObjectModelHelper.getContext(objectModel);
if (ctx != null) {
final String mimeType = ctx.getMimeType(source);
if (mimeType != null) {
return mimeType;
}
}
return inputSource.getMimeType();
}
But in this case, it was not able to get mime type of the SitemapSource.
SitemapSource, in its turn, was retrieving mimeType from the environment:
344: this.mimeType = this.environment.getContentType();
But for some reason it is not there. I think that is the problem and it was a
valid test case for this problem. Unless I am mistaken... If I'm not, we should
revert the removal of test case.
Vadim
> --
> Unico
>
> unico@apache.org wrote:
>
>> Author: unico
>> Date: Tue Oct 26 10:07:04 2004
>> New Revision: 55619
>>
>> Modified:
>> cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
>>
>> cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml
>>
>>
>> cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap
>>
>> Log:
>> remove testcase that no longer complies with expected behavior:
>>
>> internal requests should not be able to alter response headers
>> as discussed in http://marc.theaimsgroup.com/?t=109783260100005&r=1&w=2
>>
>>
>>
> <snip/>
>
Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src:
test/anteater webapp/samples/test/reader-mime-type
Posted by Unico Hommes <un...@hippo.nl>.
Now only one release blocker remains: NPE in AbstractEnvironment.release()
--
Unico
unico@apache.org wrote:
>Author: unico
>Date: Tue Oct 26 10:07:04 2004
>New Revision: 55619
>
>Modified:
> cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
> cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml
> cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap
>Log:
>remove testcase that no longer complies with expected behavior:
>
>internal requests should not be able to alter response headers
>
>as discussed in http://marc.theaimsgroup.com/?t=109783260100005&r=1&w=2
>
>
>
<snip/>