RE: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)

[Carsten Ziegeler]

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)

[Carsten Ziegeler]

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)

[Bertrand Delacretaz]

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   
12 
13   
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)

[Sylvain Wallez]

Unico Hommes wrote:



Sylvain Wallez wrote:

Carsten Ziegeler wrote:



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   
12 
13   
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)

[Unico Hommes]

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)

[Sylvain Wallez]

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)

[Jan Uyttenhove]

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  [EMAIL PROTECTED]   
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 04, 2004 1:21 PM
To: [EMAIL PROTECTED]
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 
.
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: [EMAIL PROTECTED]
   ReportedBy: [EMAIL PROTECTED]

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









smime.p7s
Description: S/MIME Cryptographic Signature

Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)

[Unico Hommes]

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)

[Bertrand Delacretaz]

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)

[Carsten Ziegeler]

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)

[Bertrand Delacretaz]

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)

[Carsten Ziegeler]

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)

[Bertrand Delacretaz]

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)

[Carsten Ziegeler]

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 04, 2004 1:21 PM
> To: [EMAIL PROTECTED]
> 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 
> .
> 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: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
> 
> 
> 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
>