Expand semantics of {query parameter separator}

The {http query parameter separator} property doesn't include a very
comprehensive explanation of it's semantics.  Instead, the semantics are
implied by statements such as "Each parameter pair is separated by the value
of the {http query parameter separator} property."  The implication is that
the separator is only used for constructing that portion of the address URL
that comes from automatically generated parameters.

 

However, query parameters can also come from the {http location} template.
That allows the user the opportunity to use two different query parameter
separators within a single URI!  For instance:

 

            <operation whttp:location="?foo=1;bar=2"
whttp:queryParameterSeparator="&"/>

 

Following the spec literally would result in a URI with both ";" and "&" as
queryParameterSeparators.  (Although the above seems rather contrived,
remember {query parameter separator} effectively defaults to "&".)

 

However, constructing the URI is only part of the potential utility of the
query parameter separator.  When parsing the URI at the server side, the URI
parser needs to know which separator to expect.  I'm not aware of any web
servers that provide parameter parsing facilities that allow multiple
separators within a single query string.  (The Java servlet API we use only
supports "&".)  The {http query parameter separator} thus has additional
utility when fed to the query string parser, to help determine where a
parameter ends and the next one begins.

 

There are a couple of things we could do in the spec to clarify query
parameter separator handling.

 

1)      Expand the semantics of {http query parameter separator} to declare
the character used as a separator in both the {http location} template and
for any auto-generated parameters.  This eliminates the ambiguity of which
is the definitive separator - that which may appear in {http location}, or
that in the {http query parameter separator} property (and its associated
default).

2)      Warn users that they should take care to make sure these two uses of
query parameter separators stay in sync, especially when the {http query
parameter separator} is defaulted.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com