Indicating whether to encode inserted attribute values

When you insert an attribute value as a URL parameter, you can specify whether Studio encodes the value before inserting it into the URL.

URLs must use ASCII characters, and must avoid using certain reserved characters used as part of the URL syntax. URL encoding replaces any non-conforming characters with a percent sign followed by a hexadecimal numeric representation of the character.

For example, the forward slash (/) is a reserved character. If a URL includes the phrase "CD/DVD", then URL encoding would change that to "CD%2FDVD".

When inserting attribute values into a URL, for components other than Results Table, to have Studio encode the inserted value, use the following format:

${attribute}

For example:

http://www.acme.com/index.htm?p1=${Attribute_1}&p2=${Attribute_2}

To not encode the value, use a double set of braces:

${{attribute}}

For example:

http://www.acme.com/index.htm?p1=${{Attribute_1}}&p2=${{Attribute_2}}

Results Table uses a slightly different system for inserting parameters. You first select a list of attributes, each of which is assigned a number. You then use the number to insert the parameter. The format uses the single and double braces to indicate encoding versus not encoding, but does not use the $. For Results Table, to have Studio encode the inserted value, use the following format:

{parameterNumber}

For example:

http://www.acme.com/index.htm?p1={0}&p2={1}

To have Studio not encode a Results Table hyperlink parameter, use a double set of braces:

{{parameterNumber}}

For example:

http://www.acme.com/index.htm?p1={{0}}&p2={{1}}

It is important to understand that avoiding encoding can pose a security risk, because data retrieved from the underlying Endeca Server is rendered in the user’s browser without intervention, potentially allowing scripts or HTML to be injected directly into a user’s browser.

Similarly, if the attribute contains reserved characters that are disallowed in a URL, the resulting hyperlink may be invalid or incorrect and therefore not work for the end user.

As a result, using the non-encoding syntax is not recommended. Unless you know that the underlying data is already encoded, you should always use the encoding syntax.