Unless I'm reading the RFC wrong,  the behaviour of
QueryStringUrlCodingStrategy is correct...

http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components

The query component contains non-hierarchical data that, along with
data in the path component, serves to identify a resource within the
scope of the URI's scheme and naming authority (if any). The query
component is indicated by the first question mark ("?") character and
terminated by a number sign ("#") character or by the end of the URI.

   query       = *( pchar / "/" / "?" )

The characters slash ("/") and question mark ("?") may represent data
within the query component. Beware that some older, erroneous
implementations may not handle such data correctly when it is used as
the base URI for relative references (Section 5.1), apparently because
they fail to distinguish query data from path data when looking for
hierarchical separators. However, as query components are often used
to carry identifying information in the form of "key=value" pairs and
one frequently used value is a reference to another URI, it is
sometimes better for usability to avoid percent-encoding those
characters.



On 4/23/09, Antoine van Wel <[email protected]> wrote:
> Hi all,
>
> using 1.3.5 :
> mounted a bookmarkable page using the QueryStringUrlCodingStrategy, now I'm
> passing in a page parameter with key "search" and value "te?t" -- the target
> url is
>
> ....?search=te?t
>
> tracing this, turns out the QueryStringUrlCodingStrategy just applies UTF-8
> encoding (or whatever has been set on the application level).
>
> Are this behavior and the constructed URL correct? I would expect a URL like
>
> ....?search=te%3Ft
>
>
> regards
> Antoine
>
> --
>
> --8<--8<--
> take your photos everywhere you go - http://www.memolio.com
> --8<--8<--
> We don't see things as they are, we see things as we are. - Anais Nin
> Whether you think you can or whether you think you can't, you're right. -
> Henry Ford
> --8<--8<--
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to