I need to implement a URL which looks something like below one. The Notable thing is that its only one parameter i need to access and the value that's supposed to be held by the parameter is encrypted which may contains characters like & and =.
The parameter v in above url contains value qww78agd=.
Supposing the encryption turns out the following way.
Then servlet will take v and f as two separate parameters, whereas i want to obatain qww7&f==iuy68= from parameter.
I thought of taking up all key value pairs from request HashMap and concatenating the joints via & and =. But the problem is that two consecutive = signs as in second case of example 2, its treated as only one equal to in request key,value map. Hence, my other = sign(s) are lost.
Is there any way such that i can get query string part as it is on my servlet and parse it using string processing on my own?
or any other approach?
Well, whoever is producing those parameters should be URL-encoding the parameter values. So if the parameter value is qww7&f==iuy68=, it should be URL-encoded as qww7%26f%3D%3Diuy68%3D. And the URL should look like this:
And to repeat, it's the responsibility of the client to do that correctly. It's not the responsibility of the server to try and fix the problems that arise when the client doesn't do that. So you should contact the people responsible for the client which generates that URL and let them know.
@Paul : There is nothing wrong with the parameter. Its encrypted value of information that fetches widget from database. Its a result of cryptographic algorithm. My goal is to be able to read it on servlet, to decytpt it.
On the contrary. URL parameters must be URL-encoded. Those aren't properly URL-encoded. It doesn't matter where it came from, whether it's the result of an encryption algorithm or somebody typing it into an HTML input field, URL-encoding is always required.
You'll find that if your client URL-encodes the URL parameters properly, then your servlet will get the correct values (the URL-decoded version) without having to do any work at all.
This has nothing at all to do with encryption, but with encoding. They are not the same thing in the least. As Paul has already pointed out, the URLs are wrong and the parameter values need to be encoded. That's all there is to it.
So, to clarify if it isn't already clear: after your client produces the encrypted value, it must then URL-encode that value before passing it as a URL parameter value. Your servlet container, when it receives the URL-encoded parameter value, will automatically URL-decode it and pass the result to your servlet. The result, of course, will be the original encrypted value.
Conversely, if the client insists on encrypting the entire queryString part of their URL and you are expected to decrypt and parse it, then you can use the HttpServletRequest getQueryString() method to obtain their encrypted query string in its totality and decrypt it.
That's only half the battle, however. If the decrypted query string is expected to contain multiple parameters and they intend to be RFC-conformant, then the unencrypted query string needs to make allowances for the presence of "reserved" querystring entities. In particular, the "&" character, but also possibly the space character (generally represented as "+" or "%20") and maybe the equal sign.
The standard servlet URL parser knows how to handle this kind of thing. If you're rolling your own, you'll have to either find some existing code or roll your own. Then use it to split out the name/value pairs. Note however, that the name name may have multiple values in a URL.
I do NOT recommend attempting to push the results of your parsing back into the HttpServletRequest object to make them look like they were decoded in the usual way. Results could be unpredictable. Anything up to and including the possibility of random crashes of your server.
Sources may include data from the Fakebook Research Foundation with support from Gargle University