Hi Oliver, I think you found known (forgotten?) bug. IIRC it was also mentioned once in August email (attached). Can you provide a patch for this?
Vadim > -----Original Message----- > From: Oliver Suck [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 31, 2001 5:19 AM > To: [EMAIL PROTECTED] > Subject: [C2] Content Aggregation and getRequestURI() > > Hi Cocooners, > > I am trying to build a complete URL inside a Saxlet by using the methods > defined in org.apache.cocoon.environment.Request. > > Depending on the fact whether or not there was a content aggregation in the > (sub)sitemap, request.getRequestURI() returns different results (request is > an instance of org.apache.cocoon.environment.wrapper.RequestWrapper). > > A partial sub sitemap is included at the end of this message. > > With content aggregation (browser URL > http://localhost:8088/cocoon/subsite/foo/index.xml.html) I get the > following results: > request.getContextPath(): "/cocoon" > request.getRequestURI(): "subsite/template/foo/index.xml" > request.getSitemapURI(): "template/foo/index.xml" > (The fragment "template" comes from the section > <map:part src="cocoon:/template/{1}/{2}"/> and shall be ignored here.) > > Without content aggregation (browser URL > http://localhost:8088/cocoon/subsite/foo/index.xml.html.foo) this looks > like: > request.getContextPath(): "/cocoon" > request.getRequestURI(): "/cocoon/subsite/foo/index.xml.html.foo" > request.getSitemapURI(): "foo/index.xml.html.foo" > > After digging through the developer mailing lists I have found a discussion > related to that specific topic back in May this year (see > http://www2.real-time.com/pipermail/cocoon-devel/2001-May/007294.html). > Unfortunately it seems as if the thread of this topic was not finished > completely (in case I missed it - sorry for that). > > The documentation of the Request Interface puts it that way: > getRequestURI() > Returns the part of this request's URL from the protocol name up to the > query string in the first line of the HTTP request. > > Now here is the question considering the method desciption: > Is request.getRequestURI() really supposed to return only a part of the > original requestURI (i.e. with the contextPath ripped off)? - As you can see > in the example without content aggregation, getRequestURI() includes the > contextPath, whereas in the example using content aggregation, the > contextPath was removed. > > How do I have to build a complete URL from the Request's methods then? > In cases without content aggregation, to me it looks like "take the > request's scheme, append the serverName, append the port if necessary, > add the requestURI and there you go (not mentioning slashes and colons)". > How can I decide inside the Java code whether there was content > aggregation or not and how the URL should be built? Just checking whether > the requestURI starts with the contextPath? Sounds a little too easy. > > Still new in this area, so don't blame me for silly questions. ;-) > > Thanks in advance! > Oliver. </snip>
Michael Homeijer wrote: > In the beta 1 of C2, in an aggregated page request:get-uri gave as result > the toplevel uri that is visible in the browser. > In the beta 2 request:get-uri results in the uri of the aggregation part. > > How do i now get the uri of the page in the xsl for the complete page? I would consider this a bug. The URI is for how a client obtains this resource--not for how the server obtains the resource. I highly recommend going back to the original result of the function. Besides that, changing the functionality is a much more subtle and dangerous way of breaking backwards compatibility. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
