The support is there for either format in .NET. Uri.EscapeUriString will use + while Uri.EscapeDataString and HttpUtility.UrlEncode will use %20. Most (all?) URL's generated in the .NET client are through a subclassed UriBuilder which ships with the framework. It should be possible to tweak that class to change the encoding, but I think it would be appropriate for the server to treat them as equivalent.
More info here: http://blogs.msdn.com/b/yangxind/archive/2006/11/09/don-t-use-net-system-uri-unescapedatastring-in-url-decoding.aspx ScottH On Mon, Dec 31, 2012 at 12:09 PM, Scott Battaglia <[email protected] > wrote: > Interesting! Is the .NET client using the native encoders for .NET? (i.e. > the Java client is using UrlEncoder.encode which conforms to the HTML > specification that you mentioned: > http://docs.oracle.com/javase/1.4.2/docs/api/java/net/URLEncoder.html). > Does Microsoft even offer an equivalent built-in class? > > What are we doing for the PHP client? > > I'd prefer if the server didn't manipulate the URLs if possible (though we > do have precedence for it since we strip jsession ids if absolutely > necessary) because people already tend to blame the server when they pass > it bad values as part of the service parameter :-) > > On Mon, Dec 31, 2012 at 11:57 AM, William G. Thompson, Jr. < > [email protected]> wrote: > >> Folks, >> >> Unicon is currently working with a client implementing an extensive >> RESTful-based architecture leveraging Proxy Tickets. We've stumbled >> on the following issue where Proxy Ticket validation is failing due to >> mismatch in how Java CAS Client and .NET CAS Client are encode spaces >> in URLs ('+' vs '%20'). >> >> URLs that include paramters with spaces like 'paramWithSpace=some >> value' are getting encoded to 'some+value' by the Java CAS client when >> requesting a PT and like 'some%20value' by the .NET CAS client on the >> validation call. This results in a "does not match supplied service" >> validation error. >> >> Seems like '+' or '%20' are both valid for space in a URL. >> >> http://www.ietf.org/rfc/rfc1738.txt says spaces should be encoded >> (presumably %20). >> >> http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 says >> spaces are replaced by '+' when form action is GET. >> >> Also see: >> >> http://stackoverflow.com/questions/1634271/url-encoding-the-space-character-or-20 >> http://bugs.python.org/issue13866 >> >> http://stackoverflow.com/questions/5366007/why-does-the-encodings-of-a-url-and-the-query-string-part-differ/5433216#5433216 >> >> Should the CAS server should accepted either form and treat them as a >> match? Open a JIRA issue against CAS Server? >> >> Best, >> Bill >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
