Return-Path: <per@onclave.com>
Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-users@xml.apache.org
Received: (qmail 56953 invoked from network); 22 Nov 2000 06:08:50 -0000
Received: from unknown (HELO onclave.com) (208.249.126.103)
  by locus.apache.org with SMTP; 22 Nov 2000 06:08:50 -0000
Received: from vader [151.204.68.169] by onclave.com with ESMTP
  (SMTPD32-6.03) id A5161110126; Wed, 22 Nov 2000 01:17:58 -0500
From: "Per Kreipke" <per@onclave.com>
To: <cocoon-users@xml.apache.org>
Subject: RE: Building a query string with '&'....
Date: Wed, 22 Nov 2000 01:08:37 -0500
Message-ID: <NDBBIKLOLMEELKELLPFIIEIDDEAA.per@onclave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <NDBBIKLOLMEELKELLPFIMEICDEAA.per@onclave.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

FYI,

The following works:

<page>
	<!-- Build the URL ahead of time -->
	<xsp:logic>
		String myUrl = "http://localhost/folders/query-feeds.xml?QueryType="
				+ URLEncoder.encode(<request:get-parameter name="QueryType"/>)
				+ "<![CDATA[&QueryText=]]>"
				+ URLEncoder.encode(<request:get-parameter name="QueryText"/>)
				+ "<![CDATA[&QueryLog=]]>"
				+ URLEncoder.encode(<request:get-parameter name="QueryLog"/>);
	</xsp:logic>
    <util:include-uri>
        <util:href>
            <xsp:expr>myUrl</xsp:expr>
        </util:href>
    </util:include-uri>
</page>

Two things made a definite difference:
- moving the string concatenation out of the <util:href> tag. The reason is
that <util:include-uri> quotes the href element and this confuses the XSP
processor. Doing this and using CDATA around the expression &QueryText=
fixed the parsing problem

Then all of a sudden, QueryText parameters with spaces in them were accepted
to this XSP file but weren't passed on correctly to the remote host being
included

- correctly re-encoding the query args fixed that.

Per.