You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Dr. Hans M. Rupp" <ha...@danet.de> on 2003/05/02 10:42:27 UTC

Manipulating the request headers in Cocoon?

Hallo!

Is there a way to manipulated request headers (e.g. Accept-Language) in
Coocon?

Many thanks,

Hans


--------------------------------------------
Dr. Hans M. Rupp
danet Internet Solutions GmbH
Waldburgstr. 17-19
70563 Stuttgart
Germany

Fon +49 711 133 53 50
Fax +49 711 133 53 53

------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Re: Manipulating the request headers in Cocoon?

Posted by e nio <en...@yahoo.com>.
  Yes I believe you can at least one way, via XSP. This snippet
is taken from cocoon204 sample XSP code
http://localhost:8080/cocoon/xsp/request  :

84   <td>get-headers accept-language (as array)
</td><td><xsp:expr>String.va
lueOf(<xsp-request:get-headers name="accept-language"
as="array"/>)</xsp:expr></td>
     85  
<td>getHeaders</td><td><xsp:expr>request.getHeaders("accept-language")
</xsp:expr></td>

Result snippet:
<td>get-headers accept-language (as array)
</td><td>[Ljava.lang.String;@ad25d0</td>
 
<td>getHeaders</td><td>org.apache.tomcat.util.http.ValuesEnumerator@8db581</td>



--- "Dr. Hans M. Rupp" <ha...@danet.de> wrote:
> Hallo!
> 
> Is there a way to manipulated request headers (e.g.
> Accept-Language) in
> Coocon?
> 
> Many thanks,
> 
> Hans
> 
> 
> --------------------------------------------
> Dr. Hans M. Rupp
> danet Internet Solutions GmbH
> Waldburgstr. 17-19
> 70563 Stuttgart
> Germany
> 
> Fon +49 711 133 53 50
> Fax +49 711 133 53 53
> 
> ------------------------------------------
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail:
> cocoon-users-help@xml.apache.org
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Re: Manipulating the request headers in Cocoon?

Posted by "Dr. Hans M. Rupp" <ha...@danet.de>.
Hallo Reinhard,

thanks for your reply.
I have tried both en or de, it doesn't make any difference. The crucial part
is the request header of the client.
Accept-Language: de
Accept-Language: en
both work.
Accept-Language: de, en
does not.

The whole header:
GET
/mb-portal/wap/weather/AW-D4?LocationId=w10738&WeatherType=Current&DisplayedLocationName=Stuttgart%2FEchterdingen&LocationType=CITY
HTTP/1.0
Host: sarasate.is.danet.de:8080
Accept: application/vnd.wap.wmlc;Type=1108, application/vnd.wap.wmlc,
application/vnd.wap.wmlscriptc, application/vnd.uplanet.signal,
application/vnd.uplanet.cacheop-wbxml, application/vnd.uplanet.alert-wbxml,
application/vnd.uplanet.channel-wbxml, application/vnd.uplanet.list-wbxml,
application/vnd.uplanet.listcmd-wbxml,
application/vnd.uplanet.bearer-choice-wbxml,
application/vnd.wap.multipart.related, application/vnd.wap.multipart.mixed,
application/x-up-device, application/vnd.phonecom.mmc-wbxml,
application/octet-stream, image/vnd.wap.wbmp, becker/vnd.wap.bim,
becker/vnd.wap.tts, becker/vnd.wap.prov, x-becker/vnd.wap.emg,
x-becker/vnd.wap.lbs, x-becker/vnd.wap.tds, x-becker/vnd.wap.dc,
image/bmp,image/vnd.wap.wbmp,application/vnd.uplanet.alert,application/x-up-alert,application/vnd.uplanet.bearer-choice,application/vnd.uplanet.cacheop,application/x-up-cacheop,application/vnd.uplanet.channel,application/vnd.uplanet.list,application/vnd.uplanet.listcmd,application/vnd.phonecom.mmc-xml,text/x-wap.wml,text/vnd.wap.wml,text/x-hdml,text/html,text/vnd.wap.wmlscript

Accept-Charset: iso-8859-1, UTF-8, *
Accept-Language: de, en
cookie: JSESSIONID=0000JQAQYCCVYKB3DLN2IJZZ4RY:-1
User-Agent: DC-S40P/10.41 UP.Browser/4.1.24c UP.Link/5.1.0.2
X-Forwarded-For: 172.25.254.218
x-up-devcap-charset: iso-8859-1
x-up-devcap-max-pdu: 2984
x-up-devcap-msize: 7,5
x-up-devcap-numsoftkeys: 4
x-up-devcap-screenchars: 20,3
x-up-devcap-screenpixels: 115,30
x-up-uplink: lh-base.t-d1-wap.de
x-up-WTLS-info: off

Greetings,

Hans

Reinhard Pötz wrote:

> What happens, if you change locale="{Weather/UserLocale}" to locale="en"
> or locale="de"?
>
> Regards,
> Reinhard
>
> > -----Original Message-----
> > From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de]
> > Sent: Friday, May 02, 2003 3:50 PM
> > To: cocoon-users@xml.apache.org
> > Subject: Re: Manipulating the request headers in Cocoon?
> >
> >
> > Hallo!
> >
> > From an earlier post:
> >
> > I have a curious problem with the i18n:date and
> > i18n:date-time tag. When I use one of these tags and access
> > the page with a specific wap-Browser, which I must support,
> > the output terminates at the first occurence of one of these tags.
> >
> > >From the xsl source:
> >
> > <b><xsl:value-of select="$name" /></b><br />
> >     <i18n:date-time src-pattern="EEEE, MMMM d, yyyy hh:mm:ss
> > a z" locale="{Weather/UserLocale}" pattern="E, dd.MM.;
> > HH.mm"><xsl:value-of
> > select="Weather/Weather/WeatherSymbol/NeutralDate"
> > /></i18n:date-time><xsl:text> </xsl:text><i18n:text>Uhr</i18n:text><br
> > />
> > ..
> >
> > Everything after the <br /> is missing in the output
> >
> > I first thought that it is a problem of the i18n transformer
> > so I checked the SAX-Events from the Trax-Transformer and the
> > i18n-Transformer and it seems that already the
> > Trax-Transformer terminates the output after the i18n date tag.
> >
> > >From the sitemap:
> >
> > <map:resource name="viewpage">
> >    <map:generate type="serverpages"
> > src="resource://weather/commonchannels/commonportals/xsp/{next
> > xsp}.xsp"/>
> >
> >    <map:transform src="xsl/{nextxsl}.xsl"/>
> >    <!-- for debugging only  remove for production -->
> >    <map:transform type="log">
> >         <map:parameter name="logfile" value="afterXSLT.log"/>
> >         <map:parameter name="append" value="yes"/>
> >      </map:transform>
> >      <!-- end for debugging only -->
> >    <map:transform type="i18n"/>
> >    <!-- for debugging only  remove for production -->
> >    <map:transform type="log">
> >         <map:parameter name="logfile" value="afterI18n.log"/>
> >         <map:parameter name="append" value="no"/>
> >      </map:transform>
> >      <!-- end for debugging only -->
> >    <map:transform type="browserAdapter"/>
> >    <map:serialize type="wml">
> >     <encoding>UTF-8</encoding>
> >    </map:serialize>
> >   </map:resource>
> >
> > from afterXSLT.log:
> >
> > [startElement]
> > uri=http://apache.org/cocoon/i18n/2.0,local=date-time,raw=i18n
> > :date-time
> >
> > [            ] 1. uri=,local=pattern,qname=pattern,type=CDATA,value=E,
> > dd.MM.; HH.mm
> > [            ] 2.
> > uri=,local=locale,qname=locale,type=CDATA,value=de_DE
> > [            ] 3.
> > uri=,local=src-pattern,qname=src-pattern,type=CDATA,value=EEEE
> > , MMMM d, yyyy hh:mm:ss a z [characters] Friday, May 2, 2003
> > 10:00:52 AM CEST [endElement]
> > uri=http://apache.org/cocoon/i18n/2.0,local=date-time,qname=i1
> > 8n:date-time
> >
> > [endElement] uri=,local=p,qname=p
> > [endElement] uri=,local=card,qname=card
> > [endElement] uri=,local=wml,qname=wml
> > [endDocument]
> >
> > Since the site works well with all web-browser I have used
> > except for the one we really do have to support I have
> > checked the differences between the headers they send. And it
> > turns out the crucial difference is the Accept-Language:
> > Accept-Language: en
> > works
> > Accept-Language: de, en
> > does not work.
> >
> > If I use the original request from the browser which does not
> > work and send it with netcat, I will get the abbreviated
> > page, if I use the same request having only the "de," removed
> > everything works fine.
> >
> > Now if this had been a problem of the i18n transformer it
> > might at least make some sense. But as I pointed out already
> > the Trax-Transformer terminates output at the i18n tag.
> >
> > (From the sitemap:
> > <map:transformer label="transformer"
> > logger="sitemap.transformer.xslt" name="xslt" pool-grow="2"
> > pool-max="32" pool-min="8"
> > src="org.apache.cocoon.transformation.TraxTransformer">
> >     <use-request-parameters>false</use-request-parameters>
> >     <use-browser-capabilities-db>false</use-browser-capabilities-db>
> >     <use-deli>false</use-deli>
> >    </map:transformer>
> > )
> >
> > I would be very gratefull for any ideas how to fix this problem.
> >
> >
> > Many thanks,
> >
> > Hans
> >
> > Reinhard Pötz wrote:
> >
> > > Maybe you can give us more details when this error occurs because
> > > request header information shouldn't have any influences to your
> > > pipelines *by default*.
> > >
> > > Reinhard
> > >
> > > > From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de]
> > > >
> > > > > The request header is set at the client side. You can read
> > > > the values
> > > > > and you can do with them whatever you want.
> > > > >
> > > >
> > > > My problem is that a specific Request-Header value coming
> > from the
> > > > client seems to cause a problem with the transformation
> > (don't ask
> > > > how a request header can disturb the XSLT transformer,
> > it's above my
> > > > head, but I have experimentally verified it), so
> > manipulationg the
> > > > request before it reaches the transformer might be a workaround if
> > > > feasible. I think there are no methods in the servlet-API to
> > > > manipulate the request. Sigh ...
> > > >
> > > > Greetings,
> > > >
> > > > Hans
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> > --
> > --------------------------------------------
> > Dr. Hans M. Rupp
> > danet Internet Solutions GmbH
> > Waldburgstr. 17-19
> > 70563 Stuttgart
> > Germany
> >
> > Fon +49 711 133 53 50
> > Fax +49 711 133 53 53
> >
> > ------------------------------------------
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org

--
--------------------------------------------
Dr. Hans M. Rupp
danet Internet Solutions GmbH
Waldburgstr. 17-19
70563 Stuttgart
Germany

Fon +49 711 133 53 50
Fax +49 711 133 53 53

------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


RE: Manipulating the request headers in Cocoon?

Posted by Reinhard Pötz <re...@gmx.net>.
What happens, if you change locale="{Weather/UserLocale}" to locale="en"
or locale="de"?

Regards,
Reinhard

> -----Original Message-----
> From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de] 
> Sent: Friday, May 02, 2003 3:50 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: Manipulating the request headers in Cocoon?
> 
> 
> Hallo!
> 
> From an earlier post:
> 
> I have a curious problem with the i18n:date and 
> i18n:date-time tag. When I use one of these tags and access 
> the page with a specific wap-Browser, which I must support, 
> the output terminates at the first occurence of one of these tags.
> 
> >From the xsl source:
> 
> <b><xsl:value-of select="$name" /></b><br />
>     <i18n:date-time src-pattern="EEEE, MMMM d, yyyy hh:mm:ss 
> a z" locale="{Weather/UserLocale}" pattern="E, dd.MM.; 
> HH.mm"><xsl:value-of 
> select="Weather/Weather/WeatherSymbol/NeutralDate"
> /></i18n:date-time><xsl:text> </xsl:text><i18n:text>Uhr</i18n:text><br
> />
> ..
> 
> Everything after the <br /> is missing in the output
> 
> I first thought that it is a problem of the i18n transformer 
> so I checked the SAX-Events from the Trax-Transformer and the 
> i18n-Transformer and it seems that already the 
> Trax-Transformer terminates the output after the i18n date tag.
> 
> >From the sitemap:
> 
> <map:resource name="viewpage">
>    <map:generate type="serverpages" 
> src="resource://weather/commonchannels/commonportals/xsp/{next
> xsp}.xsp"/>
> 
>    <map:transform src="xsl/{nextxsl}.xsl"/>
>    <!-- for debugging only  remove for production -->
>    <map:transform type="log">
>         <map:parameter name="logfile" value="afterXSLT.log"/>
>         <map:parameter name="append" value="yes"/>
>      </map:transform>
>      <!-- end for debugging only -->
>    <map:transform type="i18n"/>
>    <!-- for debugging only  remove for production -->
>    <map:transform type="log">
>         <map:parameter name="logfile" value="afterI18n.log"/>
>         <map:parameter name="append" value="no"/>
>      </map:transform>
>      <!-- end for debugging only -->
>    <map:transform type="browserAdapter"/>
>    <map:serialize type="wml">
>     <encoding>UTF-8</encoding>
>    </map:serialize>
>   </map:resource>
> 
> from afterXSLT.log:
> 
> [startElement] 
> uri=http://apache.org/cocoon/i18n/2.0,local=date-time,raw=i18n
> :date-time
> 
> [            ] 1. uri=,local=pattern,qname=pattern,type=CDATA,value=E,
> dd.MM.; HH.mm
> [            ] 2. 
> uri=,local=locale,qname=locale,type=CDATA,value=de_DE
> [            ] 3.
> uri=,local=src-pattern,qname=src-pattern,type=CDATA,value=EEEE
> , MMMM d, yyyy hh:mm:ss a z [characters] Friday, May 2, 2003 
> 10:00:52 AM CEST [endElement] 
> uri=http://apache.org/cocoon/i18n/2.0,local=date-time,qname=i1
> 8n:date-time
> 
> [endElement] uri=,local=p,qname=p
> [endElement] uri=,local=card,qname=card
> [endElement] uri=,local=wml,qname=wml
> [endDocument]
> 
> Since the site works well with all web-browser I have used 
> except for the one we really do have to support I have 
> checked the differences between the headers they send. And it 
> turns out the crucial difference is the Accept-Language:
> Accept-Language: en
> works
> Accept-Language: de, en
> does not work.
> 
> If I use the original request from the browser which does not 
> work and send it with netcat, I will get the abbreviated 
> page, if I use the same request having only the "de," removed 
> everything works fine.
> 
> Now if this had been a problem of the i18n transformer it 
> might at least make some sense. But as I pointed out already 
> the Trax-Transformer terminates output at the i18n tag.
> 
> (From the sitemap:
> <map:transformer label="transformer" 
> logger="sitemap.transformer.xslt" name="xslt" pool-grow="2" 
> pool-max="32" pool-min="8" 
> src="org.apache.cocoon.transformation.TraxTransformer">
>     <use-request-parameters>false</use-request-parameters>
>     <use-browser-capabilities-db>false</use-browser-capabilities-db>
>     <use-deli>false</use-deli>
>    </map:transformer>
> )
> 
> I would be very gratefull for any ideas how to fix this problem.
> 
> 
> Many thanks,
> 
> Hans
> 
> Reinhard Pötz wrote:
> 
> > Maybe you can give us more details when this error occurs because 
> > request header information shouldn't have any influences to your 
> > pipelines *by default*.
> >
> > Reinhard
> >
> > > From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de]
> > >
> > > > The request header is set at the client side. You can read
> > > the values
> > > > and you can do with them whatever you want.
> > > >
> > >
> > > My problem is that a specific Request-Header value coming 
> from the 
> > > client seems to cause a problem with the transformation 
> (don't ask 
> > > how a request header can disturb the XSLT transformer, 
> it's above my 
> > > head, but I have experimentally verified it), so 
> manipulationg the 
> > > request before it reaches the transformer might be a workaround if
> > > feasible. I think there are no methods in the servlet-API to
> > > manipulate the request. Sigh ...
> > >
> > > Greetings,
> > >
> > > Hans
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 
> --
> --------------------------------------------
> Dr. Hans M. Rupp
> danet Internet Solutions GmbH
> Waldburgstr. 17-19
> 70563 Stuttgart
> Germany
> 
> Fon +49 711 133 53 50
> Fax +49 711 133 53 53
> 
> ------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Re: Manipulating the request headers in Cocoon?

Posted by "Dr. Hans M. Rupp" <ha...@danet.de>.
Hallo!

>From an earlier post:

I have a curious problem with the i18n:date and i18n:date-time tag. When
I use one of these tags and access the page with a specific wap-Browser,
which I must support, the output terminates at the first occurence of
one of these tags.

>>From the xsl source:

<b><xsl:value-of select="$name" /></b><br />
    <i18n:date-time src-pattern="EEEE, MMMM d, yyyy hh:mm:ss a z"
locale="{Weather/UserLocale}" pattern="E, dd.MM.; HH.mm"><xsl:value-of
select="Weather/Weather/WeatherSymbol/NeutralDate"
/></i18n:date-time><xsl:text> </xsl:text><i18n:text>Uhr</i18n:text><br
/>
..

Everything after the <br /> is missing in the output

I first thought that it is a problem of the i18n transformer so I
checked the SAX-Events from the Trax-Transformer and the
i18n-Transformer and it seems that already the Trax-Transformer
terminates the output after the i18n date tag.

>>From the sitemap:

<map:resource name="viewpage">
   <map:generate type="serverpages"
src="resource://weather/commonchannels/commonportals/xsp/{nextxsp}.xsp"/>

   <map:transform src="xsl/{nextxsl}.xsl"/>
   <!-- for debugging only  remove for production -->
   <map:transform type="log">
        <map:parameter name="logfile" value="afterXSLT.log"/>
        <map:parameter name="append" value="yes"/>
     </map:transform>
     <!-- end for debugging only -->
   <map:transform type="i18n"/>
   <!-- for debugging only  remove for production -->
   <map:transform type="log">
        <map:parameter name="logfile" value="afterI18n.log"/>
        <map:parameter name="append" value="no"/>
     </map:transform>
     <!-- end for debugging only -->
   <map:transform type="browserAdapter"/>
   <map:serialize type="wml">
    <encoding>UTF-8</encoding>
   </map:serialize>
  </map:resource>

from afterXSLT.log:

[startElement]
uri=http://apache.org/cocoon/i18n/2.0,local=date-time,raw=i18n:date-time

[            ] 1. uri=,local=pattern,qname=pattern,type=CDATA,value=E,
dd.MM.; HH.mm
[            ] 2. uri=,local=locale,qname=locale,type=CDATA,value=de_DE
[            ] 3.
uri=,local=src-pattern,qname=src-pattern,type=CDATA,value=EEEE, MMMM d,
yyyy hh:mm:ss a z
[characters] Friday, May 2, 2003 10:00:52 AM CEST
[endElement]
uri=http://apache.org/cocoon/i18n/2.0,local=date-time,qname=i18n:date-time

[endElement] uri=,local=p,qname=p
[endElement] uri=,local=card,qname=card
[endElement] uri=,local=wml,qname=wml
[endDocument]

Since the site works well with all web-browser I have used except for
the one we really do have to support I have checked the differences
between the headers they send.
And it turns out the crucial difference is the Accept-Language:
Accept-Language: en
works
Accept-Language: de, en
does not work.

If I use the original request from the browser which does not work and
send it with netcat, I will get the abbreviated page, if I use the same
request having only the "de," removed everything works fine.

Now if this had been a problem of the i18n transformer it might at least
make some sense. But as I pointed out already the Trax-Transformer
terminates output at the i18n tag.

(From the sitemap:
<map:transformer label="transformer" logger="sitemap.transformer.xslt"
name="xslt" pool-grow="2" pool-max="32" pool-min="8"
src="org.apache.cocoon.transformation.TraxTransformer">
    <use-request-parameters>false</use-request-parameters>
    <use-browser-capabilities-db>false</use-browser-capabilities-db>
    <use-deli>false</use-deli>
   </map:transformer>
)

I would be very gratefull for any ideas how to fix this problem.


Many thanks,

Hans

Reinhard Pötz wrote:

> Maybe you can give us more details when this error occurs because
> request header information shouldn't have any influences to your
> pipelines *by default*.
>
> Reinhard
>
> > From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de]
> >
> > > The request header is set at the client side. You can read
> > the values
> > > and you can do with them whatever you want.
> > >
> >
> > My problem is that a specific Request-Header value coming
> > from the client seems to cause a problem with the
> > transformation (don't ask how a request header can disturb
> > the XSLT transformer, it's above my head, but I have
> > experimentally verified it), so manipulationg the request
> > before it reaches the transformer might be a workaround if
> > feasible. I think there are no methods in the servlet-API to
> > manipulate the request. Sigh ...
> >
> > Greetings,
> >
> > Hans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org

--
--------------------------------------------
Dr. Hans M. Rupp
danet Internet Solutions GmbH
Waldburgstr. 17-19
70563 Stuttgart
Germany

Fon +49 711 133 53 50
Fax +49 711 133 53 53

------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


RE: Manipulating the request headers in Cocoon?

Posted by Reinhard Pötz <re...@gmx.net>.
Maybe you can give us more details when this error occurs because
request header information shouldn't have any influences to your
pipelines *by default*.

Reinhard

> From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de] 
>
> > The request header is set at the client side. You can read 
> the values 
> > and you can do with them whatever you want.
> >
> 
> My problem is that a specific Request-Header value coming 
> from the client seems to cause a problem with the 
> transformation (don't ask how a request header can disturb 
> the XSLT transformer, it's above my head, but I have 
> experimentally verified it), so manipulationg the request 
> before it reaches the transformer might be a workaround if 
> feasible. I think there are no methods in the servlet-API to 
> manipulate the request. Sigh ...
> 
> Greetings,
> 
> Hans


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Re: Manipulating the request headers in Cocoon?

Posted by "Dr. Hans M. Rupp" <ha...@danet.de>.
>
>
> The request header is set at the client side. You can read the values
> and you can do with them whatever you want.
>

My problem is that a specific Request-Header value coming from the client
seems to cause a problem with the transformation (don't ask how a request
header can disturb the XSLT transformer, it's above my head, but I have
experimentally verified it), so manipulationg the request before it reaches
the transformer might be a workaround if feasible.
I think there are no methods in the servlet-API to manipulate the request.
Sigh ...

Greetings,

Hans


--
--------------------------------------------
Dr. Hans M. Rupp
danet Internet Solutions GmbH
Waldburgstr. 17-19
70563 Stuttgart
Germany

Fon +49 711 133 53 50
Fax +49 711 133 53 53

------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


RE: Manipulating the request headers in Cocoon?

Posted by Reinhard Pötz <re...@gmx.net>.
Hans,

The request header is set at the client side. You can read the values
and you can do with them whatever you want.

Of course you can change the response header.

Reinhard

> -----Original Message-----
> From: Dr. Hans M. Rupp [mailto:hans-michael.rupp@danet.de] 
> Sent: Friday, May 02, 2003 10:42 AM
> To: Coocon-user Liste
> Subject: Manipulating the request headers in Cocoon?
> 
> 
> Hallo!
> 
> Is there a way to manipulated request headers (e.g. 
> Accept-Language) in Coocon?
> 
> Many thanks,
> 
> Hans
> 
> 
> --------------------------------------------
> Dr. Hans M. Rupp
> danet Internet Solutions GmbH
> Waldburgstr. 17-19
> 70563 Stuttgart
> Germany
> 
> Fon +49 711 133 53 50
> Fax +49 711 133 53 53
> 
> ------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org