Pre-packaged solution to parse HTTP ASCII results?

[Tracy Williams]

Hi all,
I have an applet that is currently executing a PERL script on the applet's host machine. The PERL script runs a SQL query against our MySQL database and returns the results over HTTP.
The results are URL Encoded, something like:
param1=value1,¶m2=value2...
I am currently investigating how to parse the returning results. I would rather use an existing class to do this.
There is a class "HTTPRequest" (getParameter method), but it seems to be only available if you are creating a servlet.
My questions are:
1. How do I use this class if I am not creating a servlet?
2. Does anyone know of any other HTTP-parser-type class that I could use?
3. Is there a better way to do this? It bothers me that I will not be able to understand the order of the results or which parameter is being passed without some extensive logic.
Thanks in advance.
Tracy Williams

[Tim Holloway]

I'm not sure if I quite understand you, but I think one or the other will apply:
If the server is returning a URL to your applet, you can parse it using the java.net.URL class for the major components, at least. As for breaking down the operands, you might just want to see if you have source for the javax.servlet.HTTPRequest class (I'm not sure that's quite the right name and package, but something like that). If you do, you could either plunder its code or find out what utility package it's using.
URL parameter encoding isn't real complex - just a bunch of operands separated by "&" with spaces replaced by "+" and more complex characters gicen by "%" followed by a hex code. So you could split the operands with the java text parser class, use the String character subsitution class to change the "+" to space and the only really hard stuff would be the hex codes. But it's reinventing the wheel, so you should try my first suggestion and/or google for a "Java URL decoder".
More common for servlets is that they make up a URL request to a server via class HttpURLRequest and et the answer back as a stream. If you're NOT using the URLRequest class, you really should be, since it also handles the HTTP headers (including cookies for session info) automagically. Using raw socket I/O is more trouble and more stuff you have to debug. The returned stream is just that - a data stream, and is commonly lines of text or XML, though anything allowable as long as it can make it over HTTP.

[Tracy Williams]

Thanks for your reply! I'll let you know what happens.
Tracy