This is the webserver interface dialog, some of the things presented should be obvious, others not so obvious. To begin with, the domain name is without the path or access mode parts, that is, for example, you would put in furbot.dreammakersguild.com there. The access mode, either http:// or https:// is selected from the dropdown above the domain name entry. Then in the next textbox, you enter the path and filename for the page you construct for access, like for example /webtest/today.php and you're almost done. (And yes, that page does exist on this server, however, you need to keep reading before you get at it )

The rest of the dialog here is optional depending on how you configure your webaccess, the left side entries are for when you web protect the folder, or as some of you might know it, putting the .htaccess file in there with a username and password set up. In the case of the above mentioned name, well, ain't going to put ammo against me or my webserver on a public webpage. Hey, I'm crazy, not stupid.

Well, most of the time.

The final part is if you have specific predefined parameters set up for accessing the page, say for example you cannot set up web protect on your server, then you can create a set of entries here which verify that it's the bot accessing the page.

I seriously do recommend that you protect the page, especially if the page is designed to access a database on the server and modify it.

Then there's several new commands available to tinker with the web access because, obviously, the purpose is to be able to dynamically access the webserver and do things. These commands also feature a new system where I've predefined some of the selectable parameters to bot commands, and it creates a dropdown list for the parameter. For example, the WebFetch command, it will accept either GET or POST as the #0 parameter, Follow (#1) can be either TRUE or FALSE, and the GET Include can be either TRUE or FALSE. Then, for example, there's three URL stacks, the GET, POST, and USER stacks. So the Set URL Parameter command can be either GET, POST, or USER as the #0 parameter.

$WEB: Combine the URL {#0} data into variable {#1}
optionally adding onto {#2}

Takes the selected stack, puts it together as though for webaccess, and sticks the results into the named variable. If you provide anything in #2, it will tack it onto the end of that string before storing the results. 

$WEB: Remove the URL member named {#0} from the {#1} stack

Removes the named URL member, the possible stacks includes a special psuedo stack called ANY, this will cause the named member to be removed from all stacks. 

$WEB: Reset the {#0} URL parameter stack

Clears the designated stack, this contains the special selection of ALL, will zap everything. 

$WEB: Set URL {#0} Parameter {#1} to the value of {#2},
Strip Special Characters {#3}

Stores a URL parameter=value pair into the selected stack, optionally stripping special characters over encoding them. If the term of encoding special characters just confused you, remember why it's %20 instead of a space.

$WEB: Store the URL parameter named {#0} from the {#1} stack
into variable {#2} {#3}

This retrieves a value from the selected stack, if you use the special parameter ANY, it searches USER, GET, then POST in that order for the named member. The #3 parameter is either RAW or DECODED, where decoding is reverting the special characters back into the human readable form. 

$WEB: Store the URL string {#0} to the {#1} stack

Specifically for when you're using the redirection for the results, you can store the redirection URL into one of the stacks, (USER is there specifically for that purpose), and read the results rather like an extended variable, okies, a bit quirked, you DO have to extract the value into a normal variable to use, sortof like DS arrays, ... 

$WEB: Transfer, Merge, Exchange, or Copy: {#0} the {#1} stack
to the {#2} stack

Complex operation designed to mangle the stacks in the ways indicated, it's an optional means of doing things other than having to extract the contents of say, the GET stack into a string so you can set up a different type of access, you can setup, say, the POST stack with the different parameters, then swap the stacks. 

$WEB: WebFetch, using {#0}, follow redirection {#1},
include GET parameters {#2}, to variable {#3}

The most important, and actually complex, of this whole system. The first parameter is the mode, either GET or POST, if it's POST, the contents of the POST array is always included, if it's GET, you DO have to specify to include the GET parameters. If you're using the redirection return from the server for the results, then you need to set FOLLOW to FALSE, otherwise the results will be HTML Entity stripped into the result variable you specify.

To see just how freaking complex this function is, check out getWebPage and see if you can follow all the quirks involved. Do note that the bot will PAUSE execution of the script until the webserver returns a result, or the sucker times out. Also note that this is overall restricted by a timer, you cannot just do back to back hits on the server, not only is that rather impolite, and prone to error, but will bog the bot something serious. Currently it is hard limited to 60 seconds between each access, if that is proving to be too hard for people to have coded into the bot, do let me know and we will see about making some sort of override system to reduce the time limit.