[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSRP url parameters and URL Encoding questions
In 10.2.1.1.4.1 we advice "wsrp-url" values to be URL Encoded. However, we are silent on the remaining consumer rewriting tokens and their producer URL writing counterparts. But the obvious thing to do is to URL encode them all (i.e. if {wsrp-navigationalState} contains an "&" or a "/" etc then URL Encode it. Or encode it anyway just to be safe). Having URL Encoded all parameters, for producer template URL activation , the web server may even help out and do the URL decode for you. Furthermore, in order to support method GET, URL templates must avoid query strings. One strategy is to use a path ("/") instead, but I have found that (after the above helpful URL decode) some Web Servers will replace any "//" with a "/"! [A valid transformation for file paths as, e.g. file path a///b == file path a/b, but not great if one is encoding data as a path. We should not force consumers to use "#" or ";" instead of "?", as these also have issues.] Obviously this corrupts any (URL template) parameters that contain consecutive back slashes, and we can not expect producers to know what URL structure the consumer is using for it's templates. Both the decode and collapsing consecutive "/"s seem valid things for the Web server to do but they are interacting with our method=GET work around. What could we do? The simplest solution seems to be to *double* URL Encode values when replacing a {wsp-someparameter} in templates. By double encode I mean {wasp-paramValue} = HttpUtility.UrlEncode(HttpUtility.UrlEncode(RawParamValue)) or {wsrp-paramValue} = URLEncoder.encode(URLEncoder.encode(rawParamValue)); [A single URL encode should be enough for consumer rewriting. The consumer can apply a second encode on re-writing (if required).] This double encode does seem onerous at first, but has the advantage of being always safe and independent of template schemes and usesMethodGet (as well as constant for a Web Server environment & avoids us inventing a new encoding scheme). What do people think? regards, Andre
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]