|
|
 |
vaxxine.com
- WWW Services |
 |
| |
|
|
| |
|
|
| |
 |
|
|
Information
for Web Authors |
|
| |
Two Methods To Access WWW Pages
In order to support SSL services, the URL within WWW pages would have to be modified slightly to use the "https://" method
instead of the common "http://" method used for insecure pages.
Browsers that cannot support SSL are not able to access pages that are
referenced via the "https://" method. Most current browsers are able to access via the secure method. Insecure browsers will appear to "hang" when attempting to
access the secure server.
Pages cannot have a combination of secure and insecure methods. For instance, you could not have a page referenced as
"https://www.vaxxine.com/cpasswd" with a graphics embedded within using:
<IMG SRC="http://www.vaxxine.com/cpasswd/key.gif">
You can however, have a mixture of "http://" and "https://" methods to access different documents on your WWW site.
Changes In Document Root
The Secured Web Server runs under a separate "Document Root". Therefore,
pages that may currently exist under the insecure root will have to be moved. This
may cause counters, etc., to be reset. Since the general design style used by
most people is to have both a secure and insecure version of pages this should
not be an issue.
Changes In EHTML And CGI
The "old style" use of the "ehtml" directory for the storage of CGI scripts and older versions of EHTML does not work under the
secure server. Rather, the use of the ".eht" and ".cgi" extensions is required.
Processing Secured Data
After the data has been transferred securely from the browser to the WWW server
a program written to the Common Gateway Interface (CGI) will be required to
process the data after it is unencrypted.
If you are not familiar with the creation or execution of CGI scripts you may need to purchase software development time from
either Vaxxine or a third party CGI developer to create a program to process the received data.
|
|
| |
|
|
| |
|
|
|
