You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2004/03/04 13:21:16 UTC
DO NOT REPLY [Bug 27432] New: -
Malformed HTTP headers (debug information in Parameters object)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432
Malformed HTTP headers (debug information in Parameters object)
Summary: Malformed HTTP headers (debug information in Parameters
object)
Product: Cocoon 2
Version: 2.1.4
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Major
Priority: Other
Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: lars.rottmann@vodafone.com
Hello everybody,
I encountered the following issue introduced with the Cocoon-2.1.4 release.
As it turned out, a new feature of Cocoon-2.1.4 meant to provide detailed debug
information in case of an error, is the cause of the problem. Each Parameters
object given to a component is filled by Cocoon with an additional
key "org.apache.cocoon.sitemap/Location".
We use the HttpHeaderAction to add custom headers to the output stream. This
action iterates other the Parameters object and sets each Parameter as a HTTP
header.
The debug information now appears as well as a header and causes some mobiles
to refuse to display the requested content.
This bug is probably not restricted to the HttpHeaderAction alone, but most
likely affects every component iterating over all submitted Parameters instead
of picking out one directly.
Best regards
Lars
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug
information in Parameters object)
Posted by Jan Uyttenhove <ja...@xume.com>.
agreed, 'nice one' was my reaction also :-)
I ran into this already some weeks ago, probably should have reported it
on the mailling list. It is in my upgrade 'report' however :-), but I
didn't consider it a bug or so. We're using a pagination component that
started behaving really weird because of this.
What really surprised me is that this feature caused problems after an
upgrade to 2.1.4, coming from 2.1.3 (I think). I started looking in the
changes list and I found an entry for this [1] *before* the release of
2.1.3. Probably I didn't notice it in 2.1.3, but it should be there ever
since. I find it really strange that nobody reported problems with this
before, so I thought it was a well considered and intended 'feature'
instead of a possible 'bug' :-)
Jan
[1] "Sitemap components (matchers, actions, generators, etc) can know
the location of their use in the sitemap unsing a special parameter
named Constants.SITEMAP_PARAMETERS_LOCATION"
Jan Uyttenhove jan.uyttenhove@xume.com
> Xume < - http://www.xume.com
Carsten Ziegeler wrote:
> Wow, that's a nice one :)
>
> Now, I think passing this debug information into the Parameters is not
> the correct way to go. It can cause - as we see - problems and in
> addition this is an incompatible change! So all sitemap components
> that are iterating over the parameters object are affected by this
> problem.
>
> I think, we should disable this feature for now and find a better
> and compatible way.
>
> Anyone against this?
>
> Carsten
>
>
>>-----Original Message-----
>>From: bugzilla@apache.org [mailto:bugzilla@apache.org]
>>Sent: Thursday, March 04, 2004 1:21 PM
>>To: dev@cocoon.apache.org
>>Subject: DO NOT REPLY [Bug 27432] New: - Malformed HTTP
>>headers (debug information in Parameters object)
>>
>>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED
>>COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432>.
>>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
>>INSERTED IN THE BUG DATABASE.
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432
>>
>>Malformed HTTP headers (debug information in Parameters object)
>>
>> Summary: Malformed HTTP headers (debug information
>>in Parameters
>> object)
>> Product: Cocoon 2
>> Version: 2.1.4
>> Platform: Sun
>> OS/Version: Solaris
>> Status: NEW
>> Severity: Major
>> Priority: Other
>> Component: core
>> AssignedTo: dev@cocoon.apache.org
>> ReportedBy: lars.rottmann@vodafone.com
>>
>>
>>Hello everybody,
>>
>>I encountered the following issue introduced with the
>>Cocoon-2.1.4 release.
>>
>>As it turned out, a new feature of Cocoon-2.1.4 meant to
>>provide detailed debug information in case of an error, is
>>the cause of the problem. Each Parameters object given to a
>>component is filled by Cocoon with an additional key
>>"org.apache.cocoon.sitemap/Location".
>>
>>We use the HttpHeaderAction to add custom headers to the
>>output stream. This action iterates other the Parameters
>>object and sets each Parameter as a HTTP header.
>>The debug information now appears as well as a header and
>>causes some mobiles to refuse to display the requested content.
>>
>>This bug is probably not restricted to the HttpHeaderAction
>>alone, but most likely affects every component iterating over
>>all submitted Parameters instead of picking out one directly.
>>
>>Best regards
>>
>>Lars
>>
>
>
>
>
>
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 4 mars 2004, à 22:56 Europe/Zurich, Sylvain Wallez a écrit :
> ....Although individual parameter location may be useful, the location
> parameter I'm talking about is that of the statement. This makes me
> think "SitemapParameters" with a "getStatementLocation()" is better
> than "LocatedParameters" I suggested above.
>
> Let's consider the following snippet:
> 10 ...
> 11 <map:generate src="foo.xml">
> 12 <map:parameter name="bar" value="baz"/>
> 13 </map:parameter>
> 14 ...
>
> ((SitemapParameters)parameters).getStatementLocation() -->
> "sitemap.xmap:11:2"
> parameters.getLocation("bar") --> "sitemap.xmap:12:4"
>
> getLocation(name) can be useful to notify a problem about a particular
> parameter, while getStatementLocation() relates to the whole > statement.
>
> getLocation(name) can also be useful for Parameterizable components,
> as it replaces Configuration.getLocation() which is no more available.
Sounds good, having both is certainly useful for error reporting.
Just a detail, how about casting to a SitemapLocation interface instead
of classes?
((SitemapLocation)parameters).getStatementLocation() -->
"sitemap.xmap:11:2"
And assuming you get plain Parameters
((SitemapLocation)parameters).getParameterLocation("bar") ->
"sitemap.xmap:12:4"
-Bertrand
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug
information in Parameters object)
Posted by Sylvain Wallez <sy...@apache.org>.
Unico Hommes wrote:
>
>
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>
<snip/>
>>> But then you have to change every component that currently iterates
>>> over the parameters and every component has to filter.
>>> We actually really introduced an incompatible feature and to be
>>> honest, I don't even know where it is used and if it's useful at all.
>>
>>
>> I'm the one who introduced this feature: it allows every sitemap
>> component to know the location from where it is invoked, which allows
>> more meaningful messages to be produced by these components. You can
>> find some example usage of this in e.g. AbstractWildcardMatcher and
>> AbstractProcessingPipeline.
>>
>> The parameters object is the only one that is related to a particular
>> usage of a component in a sitemap statement, and therefore the only
>> place where this information can be stored.
>>
>> Now I understand the problem Lars encountered, and I'm sorry to have
>> missed that when I implemented that feature (I don't use these
>> parameter-iterating actions).
>>
>> So how do we solve this? I do want to keep this information which is
>> an important means to provide more help to the developper in case of
>> problem.
>>
>> So here's a proposal (I should have thought about it way earlier...):
>> let's use a "LocatedParameters", subclass of "Parameters" with an
>> additional "getLocation()" method. It has no impact on components
>> that iterate on parameters, and yet still provide location whenever
>> it's needed.
>>
>
> Does it make sense to narrow the location down even more by passing
> the parameter name with that method?
>
> location = parameters.getLocation(name);
>
> I am surprised this isn't part of the Parameters interface already.
Although individual parameter location may be useful, the location
parameter I'm talking about is that of the statement. This makes me
think "SitemapParameters" with a "getStatementLocation()" is better than
"LocatedParameters" I suggested above.
Let's consider the following snippet:
10 ...
11 <map:generate src="foo.xml">
12 <map:parameter name="bar" value="baz"/>
13 </map:parameter>
14 ...
((SitemapParameters)parameters).getStatementLocation() -->
"sitemap.xmap:11:2"
parameters.getLocation("bar") --> "sitemap.xmap:12:4"
getLocation(name) can be useful to notify a problem about a particular
parameter, while getStatementLocation() relates to the whole statement.
getLocation(name) can also be useful for Parameterizable components, as
it replaces Configuration.getLocation() which is no more available.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug
information in Parameters object)
Posted by Unico Hommes <un...@hippo.nl>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Bertrand Delacretaz wrote:
>>
>>
>>> Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :
>>>
>>>
>>>
>>>> ...I think, we should disable this feature for now and find
>>>
>>> a better
>>>
>>>> and compatible way....
>>>>
>>>
>>> Wouldn't just changing the header name from
>>> org.apache.cocoon.sitemap/Location to something like
>>> X-Cocoon-debug-sitemap-location fix the problem?
>>>
>>>
>>
>> Perhaps in this special case, I don't know, perhaps Lars can answer this.
>>
>>
>>
>>> Using a known prefix like "X-Cocoon-debug-" also makes it easy to
>>> filter out these headers when needed.
>>>
>
>
> This information is absolutely not meant to be sent back to the browser!
>
>> But then you have to change every component that currently iterates
>> over the parameters and every component has to filter.
>> We actually really introduced an incompatible feature and to be
>> honest, I don't even know where it is used and if it's useful at all.
>>
>>
>
> I'm the one who introduced this feature: it allows every sitemap
> component to know the location from where it is invoked, which allows
> more meaningful messages to be produced by these components. You can
> find some example usage of this in e.g. AbstractWildcardMatcher and
> AbstractProcessingPipeline.
>
> The parameters object is the only one that is related to a particular
> usage of a component in a sitemap statement, and therefore the only
> place where this information can be stored.
>
> Now I understand the problem Lars encountered, and I'm sorry to have
> missed that when I implemented that feature (I don't use these
> parameter-iterating actions).
>
> So how do we solve this? I do want to keep this information which is an
> important means to provide more help to the developper in case of problem.
>
> So here's a proposal (I should have thought about it way earlier...):
> let's use a "LocatedParameters", subclass of "Parameters" with an
> additional "getLocation()" method. It has no impact on components that
> iterate on parameters, and yet still provide location whenever it's needed.
>
Does it make sense to narrow the location down even more by passing the
parameter name with that method?
location = parameters.getLocation(name);
I am surprised this isn't part of the Parameters interface already.
Unico
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
> >
> > So here's a proposal (I should have thought about it way
> earlier...):
> > let's use a "LocatedParameters", subclass of "Parameters"
> > with an additional "getLocation()" method. It has no impact on
> > components that iterate on parameters, and yet still
> provide location
> > whenever it's needed.
> >
> > WDYT?
>
> +1, I had the same this night :)
^^^^
idea
Grmpf
Carsten
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> So here's a proposal (I should have thought about it way earlier...):
> let's use a "LocatedParameters", subclass of "Parameters"
> with an additional "getLocation()" method. It has no impact
> on components that iterate on parameters, and yet still
> provide location whenever it's needed.
>
> WDYT?
+1, I had the same this night :)
Carsten
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug
information in Parameters object)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Bertrand Delacretaz wrote:
>
>
>>Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten
>>Ziegeler a écrit :
>>
>>
>>
>>>...I think, we should disable this feature for now and find
>>>
>>>
>>a better
>>
>>
>>>and compatible way....
>>>
>>>
>>Wouldn't just changing the header name from
>>org.apache.cocoon.sitemap/Location to something like
>>X-Cocoon-debug-sitemap-location fix the problem?
>>
>>
>>
>Perhaps in this special case, I don't know, perhaps Lars can answer this.
>
>
>
>>Using a known prefix like "X-Cocoon-debug-" also makes it
>>easy to filter out these headers when needed.
>>
>>
This information is absolutely not meant to be sent back to the browser!
>But then you have to change every component that currently iterates over the parameters and every component has to filter.
>
>We actually really introduced an incompatible feature and to be honest, I don't even know where it is used and if it's useful at all.
>
>
I'm the one who introduced this feature: it allows every sitemap
component to know the location from where it is invoked, which allows
more meaningful messages to be produced by these components. You can
find some example usage of this in e.g. AbstractWildcardMatcher and
AbstractProcessingPipeline.
The parameters object is the only one that is related to a particular
usage of a component in a sitemap statement, and therefore the only
place where this information can be stored.
Now I understand the problem Lars encountered, and I'm sorry to have
missed that when I implemented that feature (I don't use these
parameter-iterating actions).
So how do we solve this? I do want to keep this information which is an
important means to provide more help to the developper in case of problem.
So here's a proposal (I should have thought about it way earlier...):
let's use a "LocatedParameters", subclass of "Parameters" with an
additional "getLocation()" method. It has no impact on components that
iterate on parameters, and yet still provide location whenever it's needed.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug
information in Parameters object)
Posted by Unico Hommes <un...@hippo.nl>.
Bertrand Delacretaz wrote:
> Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
>
>> ...Yes, so if someone knows where this is used/useful we can perhaps
>> think about an alternative.
>
>
> It is used to add location info to Exceptions, for example in
> o.a.c.matching.AbstractRegexpMatcher.preparedMatch()
> (search for SITEMAP_PARAMETERS_LOCATION).
>
Sitemap statement location information is present on the sitemap
processor level. If you look at PreparableMatchNode class you'll see it
is quite easy to augment the exception with location information there.
Unico
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
> ...Yes, so if someone knows where this is used/useful we can perhaps
> think about an alternative.
It is used to add location info to Exceptions, for example in
o.a.c.matching.AbstractRegexpMatcher.preparedMatch()
(search for SITEMAP_PARAMETERS_LOCATION).
-Bertrand
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> Le Jeudi, 4 mars 2004, à 15:01 Europe/Zurich, Carsten
> Ziegeler a écrit :
>
> > Bertrand Delacretaz wrote:
> >> ...Using a known prefix like "X-Cocoon-debug-" also makes
> it easy to
> >> filter out these headers when needed.
> >>
> > But then you have to change every component that currently iterates
> > over the parameters and every component has to filter.
>
> Yes, right. debugging info is not Parameters. There must be a
> better way.
>
Yes, so if someone knows where this is used/useful we can perhaps
think about an alternative.
Carsten
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 4 mars 2004, à 15:01 Europe/Zurich, Carsten Ziegeler a écrit :
> Bertrand Delacretaz wrote:
>> ...Using a known prefix like "X-Cocoon-debug-" also makes it
>> easy to filter out these headers when needed.
>>
> But then you have to change every component that currently iterates
> over the parameters and every component has to filter.
Yes, right. debugging info is not Parameters. There must be a better
way.
-Bertrand
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten
> Ziegeler a écrit :
>
> > ...I think, we should disable this feature for now and find
> a better
> > and compatible way....
>
> Wouldn't just changing the header name from
> org.apache.cocoon.sitemap/Location to something like
> X-Cocoon-debug-sitemap-location fix the problem?
>
Perhaps in this special case, I don't know, perhaps Lars can answer this.
> Using a known prefix like "X-Cocoon-debug-" also makes it
> easy to filter out these headers when needed.
>
But then you have to change every component that currently iterates
over the parameters and every component has to filter.
We actually really introduced an incompatible feature and to be honest,
I don't even know where it is used and if it's useful at all.
Carsten
Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :
> ...I think, we should disable this feature for now and find a better
> and compatible way....
Wouldn't just changing the header name from
org.apache.cocoon.sitemap/Location to something like
X-Cocoon-debug-sitemap-location fix the problem?
Using a known prefix like "X-Cocoon-debug-" also makes it easy to
filter out these headers when needed.
-Bertrand
RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Wow, that's a nice one :)
Now, I think passing this debug information into the Parameters is not
the correct way to go. It can cause - as we see - problems and in
addition this is an incompatible change! So all sitemap components
that are iterating over the parameters object are affected by this
problem.
I think, we should disable this feature for now and find a better
and compatible way.
Anyone against this?
Carsten
> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Thursday, March 04, 2004 1:21 PM
> To: dev@cocoon.apache.org
> Subject: DO NOT REPLY [Bug 27432] New: - Malformed HTTP
> headers (debug information in Parameters object)
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED
> COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27432
>
> Malformed HTTP headers (debug information in Parameters object)
>
> Summary: Malformed HTTP headers (debug information
> in Parameters
> object)
> Product: Cocoon 2
> Version: 2.1.4
> Platform: Sun
> OS/Version: Solaris
> Status: NEW
> Severity: Major
> Priority: Other
> Component: core
> AssignedTo: dev@cocoon.apache.org
> ReportedBy: lars.rottmann@vodafone.com
>
>
> Hello everybody,
>
> I encountered the following issue introduced with the
> Cocoon-2.1.4 release.
>
> As it turned out, a new feature of Cocoon-2.1.4 meant to
> provide detailed debug information in case of an error, is
> the cause of the problem. Each Parameters object given to a
> component is filled by Cocoon with an additional key
> "org.apache.cocoon.sitemap/Location".
>
> We use the HttpHeaderAction to add custom headers to the
> output stream. This action iterates other the Parameters
> object and sets each Parameter as a HTTP header.
> The debug information now appears as well as a header and
> causes some mobiles to refuse to display the requested content.
>
> This bug is probably not restricted to the HttpHeaderAction
> alone, but most likely affects every component iterating over
> all submitted Parameters instead of picking out one directly.
>
> Best regards
>
> Lars
>