You are on page 1of 3

PPSuite Web Server

2005, Objectif Lune This software is for demonstration purposes only and may not be used without written consent from Objectif Lune. Any unauthorized use will be considered an infringement of copyright and will be prosecuted.

Abstract
PPSuite Web Server is a barebones HTTP Server that handles HTTP GET requests and saves them to XML disk files. These XML disk files can then be processed by PlanetPress Watch. PPSuite Web Server is a System Tray application, which means when you close or minimize it, it sits in the system tray. Right clicking on its icon in the gives you the option to Configure the application or Close it completely.

How to use it
To access the PPSuite Web Server, an end user only needs a standard Web Browser application. To monitor and restrict traffic on the PPSuite Web Server, a list of authorized users must be created. Each user has a name and a corresponding file path/name in which their requests are saved on the server. To send a request, the user types in the URL of the server, followed by its user name - as if it were the address for a Web page - and then followed by a variable number of [name=value] pairs of arguments.

Example
For instance, let's say a user named John Doe has already been added to the list of authorized users as JDoe and wants to send a request to the PPSuite Web Server. John would launch his web browser, and in the URL he would type something like the following:
http://127.0.0.1/JDoe?FirstVar=First Value&SecondVar=Second Value&ThirdVar=Third Value

Note: The IP Address (127.0.0.1) in this example must be changed to the actual IP address of the server on which PPSuite Web Server is installed. If the user's file path/name in which to save his requests is, for instance C:\Requests\JDoe.xml then after John has sent the request, the contents of that file on the PPSuite Web Server will look like this: <?xml version="1.0" ?> <PPSERVER_WEB_REQUEST> <FirstVar>First Value</FirstVar> <SecondVar>Second Value</SecondVar> <ThirdVar>ThirdValue</ThirdVar> </PPSERVER_WEB_REQUEST>

Users
Users can be added, edited and deleted. Additionally, users can remain in the list but be deactivated on the Server by removing the checkmark next to their name in the User List. If you don't want to manage users, just create a single user and let anyone connect to that user name. Read the Known Issues below, though, as you might be overwriting the user's XML files if you do that.

Console

The console lists all connections as they happen, along with a status of the operation. Messages are pretty much self-explanatory.

Other options
... are pretty much self explanatory too.

Response File
However, a cool one is available that does require a few additional explanations: Use Response file, in the Connection section. This allows you to specify which HTML file will be sent back to the user when their request has been handled successfully. When no response file is specified, the system responds to each successful request with a fairly drab message:

Request sent to server successfully.


You can make things a little livelier by selecting an HTML file instead. And that HTML file can contain references to the parameters sent by users in their request so you can use them in your response automatically. For instance, let's say the user is generating a request with the following parameter/value pairs: (...)/user?Firstname=John&Lastname=Doe The web server can insert those values in your HTML response file before sending it back to the user. For instance, you could use the following syntax for the HTML response file: <HTML> <BODY> <H1>Your request was sent successfully, <B>%%V1%%</B>.</h1> </BODY> </HTML> In this instance, the user would receive the following response:

Your request was sent successfully, John.


Notice the %%V1%% syntax in the HTML code above. It means: insert Value number 1 from the parameters list into the response file. You may use the V1, V2, V3 etc. variables as often as you like in the response file (remember to always put them between pairs of %%.). You can also use a parameter's name (as opposed to its value described above) by using the following syntax: %%P1%%. Again, you can use P1, P2, P3 etc. as often as you like. Now here's a more elaborate example for a response file. Let's say this time the user is generating a request with the following parameter/value pairs: (...)/user?Firstname=John&Lastname=Doe&city=Denver&favoritecolor=Red Using the following response file: <HTML> <BODY> <H1>Thank you, <B style="color: %%V4%%">%%V1%%</B>.</h1> Your request, sent from the beautiful %%P3%% of %%V3%% will be processed shortly.<BR> </BODY> </HTML>

The user would receive a response that looks like this:

Thank you, John.


Your request, sent from the beautiful city of Denver will be processed shortly. Notice how John's name appears in red. That's because we used the value from the favoritecolor parameter to set the style of the color for the bold attribute ( <B style="color: %%V4%%">) before specifying the user's name. That means the parameter names and values cannot only be used for textual reference within the response file, but also as HTML (and even, as is the case here, as CSS) attributes to change its appearance. I won't get into the details of HTML and CSS syntax because that's definitely outside the scope of this document. But at least, now you know how to use the parameters within the response file. Limitations of the response file: 0* You can't include references to any other files inside the response file. Therefore, no images (through the <IMG> token, for instance) can be included in the response (unless they point to another server.... reason being that this here barebones server just doesn't know how to deliver its own images to its clients!) 1* Care must be taken to use only variables (V1, V2, P1, P2, etc) that actually exist in the users's request. If you reference P6 in your response file and the user only sends 4 parameters, the textual value %%P6%% will appear verbatim in the response sent to the user, since the server doesn't try to replace it with an actual value. 2* Make sure you've considered all possibilities: if a user can send requests with empty values, your response file should be built around that fact because even though the parameter exists, it can in fact be empty so for instance, the %%V1%% value will be replaced with nothing.

Known Issues 3* Changing the HTTP port to be monitored does not work (even though the Server says it 4*
does). You must exit from the application and launch it again before the new setting works. Remember, this is a demo. If you keep the server running long enough and connections are made on a regular basis, the console will probably hog all of the OS's memory because it never clears all of the previous lines. So you might want to stop the application and start it again from time to time. Remember, this is a demo. Right now, if a user connects twice in a row to his page, the Server will overwrite the existing XML file for that user if PlanetPress Watch hasn't yet picked up the first file. Remember, this is a demo. Configuration is saved in the Registry, under the HKEY_CURRENT_USER\Software\Objectif Lune\PPSuiteWeb key. I have no idea if that's any kind of problem with any sorts of user permissions. Remember, this is a demo. Many other options are missing. Remember, this is a demo.

5* 6* 7*

You might also like