HTTP & GOPHER SERVERS FOR JNOS 1.11x4

Here goes the http and gopher additions to the 1.11x4 version along with some improvements in the ftp server, etc. Enjoy! Thanks to Phil Karn (KA9Q) for this wonderful creation.

Table of Contents

• HTTP & GOPHER SERVERS FOR JNOS 1.11x4
  • FTP SERVER:
  • GOPHER:
  • HTTP:
  • HOW TO MAKE:
  • COMMENTS:

FTP SERVER:

• Some cleaning up and code efficiency. Commands added and fixed:
  • RNFR & RNTO commands added to rename files (ported from Tnos).
  • APPE command added to append files.
  • HELP command added. NOOP command fixed.
  • SIZE command added. (Netscape needs it to show the d/l estimates.)

  Note: Some of these commands have become a part of the standard JNOS in the mean time.

• Unix-like relative interpretation of absolute paths. e.g. if anonymous has "/pub" as his firstpath then the commands CWD, RETR, RSME, LIST & NLST would interpret "/yyyy.xxx" as "/pub/yyyy.xxx" if "/yyyy.xxx" is not permitted.

• A new sysop command ftpmax [n] added to restrict the number of concurrent ftp connections.

• The ftp permissions work a little differently than standard JNOS: if a user has any kind of access to a directory, he/she has also LIST access to that directory.

• If Unix-like dir is defined, "SYST" command reports "Unix", and "JNOS" in banner is replaced with "J*N*O*S" to make WS_FTP to work correctly in auto detect mode.

• Note: There is also a version of ftp server that uses only binary transfers. Since, MSDOS's and internet's EOL sequences are the same we can take advantage of this fact and do all the transfers in binary mode as long as we have opened the files in binary mode, too. But, you cannot use LZW compression in this case. The advantage of binary transfers is that they are much faster. If you want to have the all binary server than get the FTPSERV.C from the jnos/www/alt/ dir and replace the one in www.zip with it.

GOPHER:

• There is nothing really new here compared to the previous version except access restrictions. Gopher server simply refuses to serve anything from the paths listed in the access file. Since GOPHER protocol unlike HTTP doesn't have a user password verification method, this is the only option we have.

• Root gopher directory can be changed from nos.cfg file with the line "Gopherdir = /path"; default is /gopher.

• The URLs can be given as either drive:/path or just /path. In the latter case, a drive letter is prepended to the path. The default is C:. You can change this with the sysop command gopher drive [c], where [c] is the drive letter. (Of course, the gopher document type codes are also necessary. See, gopsetup.txt for detailed information.)

• The CSO database file should be called "cso.dbf" and should reside in the DOS default directory while Jnos is running.

• You can run as many gopher servers as you want - subject to memory restrictions, of course -, each listening on a different port and using a different root directory and CSO database file without any duplicated code as in Ashok's gofer2 server. Just give the command start gopher [port#]. The root directory for the server listening on port 333 would be /g333 and, the CSO file would be cso333.dbf.

• Addition of

  gopher maxcli [n],
  gopher tdisc [secs], and
  gopher simult [n] sysop commands.

  maxcli

  
  

  
  

  sets the number of simultaneous gopher connects allowed; the rest gets immediately disconnected, default is 10.

  tdisc

  sets the number of seconds allowed from the connection till to the request. So that, somebody cannot block our gopher server just by connecting and sitting idle there. Default is 180 secs.

  simult

  sets the maximum number of simultaneous requests serviced. If there are more then this but less than maxcli connections, the later ones will wait on a queue. Reason for this command: we don't want to reject requests unnecessarily, but we also don't want to crash because of too much load at once either.

• For the detailed instructions about the GOPHER server and its search engines you should get the gopsetup.txt file. This file is a somewhat modified version of a very old document and has some inconsistencies with this one. In such cases, this document should be assumed correct.

• Note: All file transfers are done in binary mode for speed. I am beginning to think of dropping the gopher server of this package. Hardly anybody uses it on the internet anymore. The only reason I am still keeping it is its search engines (which I don't use) and the CSO phone book searches (which I maintain, but hardly ever gets to be used). Now, with the new extensions to the HTTP server code. It isn't really hard to transfer those functionalities to the WWW server.
  Also, the GOPHER server code was quite seriously buggy to begin with. Although, I did some serious debugging a long time ago, the code is still at least cluttered and inefficient. It is bigger than the HTTP server!

HTTP:

Almost completely rewritten it again. I took a lot of code and ideas from Brian Lantz' adaptation of the http server to TNOS. An unfortunate effect of this is backwards incompatibility. So, be careful and read this document thoroughly.

•  

  Setup

  Multiple http servers each listening on a different port number, and using a different root path can be run. The maximum number of servers is compile time configurable and is 5 by default. This document will explain the setup of only one. But, it applies to each instance of the server.

  • First decide about which drive and path you will use as the root location for this server. Only files in this directory or its sub directories will be available to the server. Well, there is a way to override this, but that's later. Default drive is C and the default path is /gopher.
  • Create the directory you chose above. If this is your primary server; Create a file called access in your spool directory. The contents of the access file will be explained later. Access file must exist even if empty.
  • Detailed logging for HTTP requests are possible. If you want this feature, you should #define HTTP_EXTLOG in config.h file. The http log files will be kept in the "/wwwlogs" directory which will be in Jnos' root directory. The placement of this directory can be changed from the nos.cfg file with a line like this: HLogsDir = /dir1/dir2. Every day, a new log file will be started in this directory. The naming convention for the log file is exactly like the general log files. So, you can use Karl-Heinz Weiss' cleanlog utility on these files.
  • Now, write your first HTML document, name it root.html, and put it into your chosen root directory. (I will assume that it is 'c:/gopher' from this point on.)
  • You can start the server, now. The JNOS console command for this is:

    start http [port#] [d] [rootdir]

    If you omit the bracketed options, the defaults are [port#] == 80; [d] == 'C'; [rootdir] == '/gopher'.

    • Example: start http 80 c /gopher (defaults)

• Configuration commands

  http absinclude [on|off]

  Allow absolute paths to be included

  http always [on|off]

  If on, html files will always be sent regardless of their modification time. (If you use SSIs in your html files, then the file modification time of the html file is not indicative of the content change.)

  http dontlog [str1[|str2[|..]]]

  If you compiled in detailed logging option, this command lets you define strings which if contained in the URL, will suppress detailed logging for these connections.

  Example: http dontlog junkdir/|.gif|.jpg

  http maxcli [n]

  Max. number of connections allowed at one time

  http multihomed [on|off]

  If your server has more than one IP addressses, sets this to on. Defaults to off.

  http simult [n]

  Max. number of connections serviced at once, the rest will wait

  http status

  Shows information about started servers

  http tdisc [secs]

  Set the inactivity disconnect timer

• URLs and Access to the Server

  • The documents on your server can be accessed with URLs of the form:
    http://your.internet.address/c:/dir1/dir2/file.ext

    The drive designation in the URL can be dropped, in which case, the drive you have set in the start command will be used. And dir1 is a sub directory of the [rootdir]

  • If the path points to a sub directory then the file welcome.htm in that directory will be served. If it doesn't exist, a directory listing will be prepared on the fly.
    • Note: The wwwpre.cat and wwwpost.cat files are NOT supported anymore. But, you can get the same functionality (and much more) via SSI.
  • welcome.nhd can be used instead of the welcome.htm. In which case, welcome.nhd will be sent w/o HTTP/1.0 headers. This feature can be utilized to do unusual things like automatic redirection. (Probably, not necessary anymore with todays intelligent browsers.)

• Basic Authorization Scheme

  • It is possible to require user-password authorization for some paths under the [rootdir]. Jnos uses the Basic Authorization Scheme. Which requires the client to send the username:password string in BASE64 encoded form.
  • To restrict access to, say, /gopher/secret directory with user guest and password hello, put a line like:
    /secret TopSecretArea Z3Vlc3Q6aGVsbG8=

    into the access file created above.

    • The first entry on the line is the restricted path relative to [rootdir], must begin with a '/' character, and no drive letter.
    • Second is the realm name. You should use the same realm name for all paths that require the same user - password pair, but different ones must be used otherwise.
    • The last entry on the line is BASE64 encoded form of user:password string. There is a small utility called base64.exe in the www.zip which you can use to generate this string. To generate the above example execute the command
      base64 guest:hello

      at the DOS prompt. Be careful to exactly copy the output to the access file.
      

  • If you want a directory not to be accessible even with a password, just put its relative path without a realm and passkey.
  • I tried to plug in all the holes in this system. But, if you discover any loopholes in the security of this server, please report to seost2+@pitt.edu.

• Server Side Includes

  • The current version is completely incompatible with the previous versions in SSI syntax. It is much more powerful and flexible. And also, is compatible with NCSA httpd server. (With some omissions and additions.)
  • The general syntax for an SSI command is:
    <!--# cmdname tag="value" -->

    where tag depends on cmdname, and value depends on tag. Here is a list of commands and their associated tags:

    • echo
      Prints the values of some variables.
      • var tag for the echo command can take one of these values:
        • DATE_LOCAL Current local time
        • DATE_GMT Current GMT time
        • HOSTNAME Hostname of the server
        • DOCUMENT_URI Resource Identifier of the current document on this server
        • DOCUMENT_NAME File name of the current document
        • LAST_MODIFIED Current document modification time
        • TOTAL_HITS Total number of hits to this server
        • REQ_FROM The From: header value of request (if given by browser)
        • REQ_REFERER The referring URL (if given by browser)
        • REQ_AGENT The accessing browser program name (if given by browser)
      • dcount Display the named counter
      • icount Increment and display the named counter
      • scount Increment only
        Each of these three count tags takes a filename as value which is created in "/wwwstat" directory, and used to keep a counter in. "/wwwstat" directory will be created in the Jnos' root directory by default. Its placement can be changed from nos.cfg file with a line like this: HttpStatsDir = /dir1/dir2.

    • include
      Inserts other files and directories into the current document.
      • file takes the absolute path of a file or directory to be included. You have to issue the http absinclude on command for this to work. Look at the setup section for this command.
      • virtual takes a path like /dir/file.ext which is interpreted relative to [rootdir].
      • Both file and virtual can also take a directory path as a value. If that is the case, the path must end with a '/' character. Otherwise, it wouldn't work.

    • exec
      • cgi takes a cgi function URI as value and executes it.

  • Each SSI command must begin and end on a single line. There can be text and/or other SSI commands on the same line, but the total length of the line must not exceed 255 characters.

  • Examples:
    • <!--# echo var="DATE_LOCAL" -->
    • <!--# echo icount="page1.cnt" -->
    • <!--# include virtual="file2.htm" -->
    • <!--# exec cgi="/cgi_function?arguments" -->

• CGI Functionality

  This version of the HTTP server has a sort of cgi support. Actually, it is just an interface for further extension of the server code. I thought a lot about how we can support some form and query processing in this server. Any general form processing function I could think of would be too limited. Some kind of scripting language seemed as a possibility, but anything useful and flexible enough would require a lot of memory and would exceed my programming abilities. So, at last, I decided to define a uniform interface and provide a hook for the extension of the server source code. That means, if you know C and the basics of the Jnos code, and a little of the HTTP 1.0 specification, you can write functions for form processing and hook it up with the server source code easily. And since the interface is uniform, these functions can be exchanged between people.

  What you have to do is just write a C function which has a certain prototype, and register it in the Cgis[] array in http.c, and that function will be called with all the necessary information passed to it. Then you just have to process the info whichever way you want, and produce an output for the client.

  I won't talk about the programming details of this here. I tried to explain how it works in the http.c to which you will append your functions. I also included two such functions to demonstrate the way they work: One is a simple x-bitmap graphic hit counter which I have been using for quite a while to supply hit counting service to my friends who have their pages on a server which doesn't allow SSI. The other is a simple form entry logging function which is solely for demonstration purposes. Neither of them are compiled in by default. If you want to see their functioning, you have to turn two '#undef's in http.c to '#define's.

  Important Comments (A must read section)

  • SSI commands can be quite dangerous. Be very careful in using them. They are recursive; ie. an included file can include further files. I think this is a nice feature. But, don't abuse it, as each recursion would use up some memory. More importantly, beware of the inclusion loops; they will certainly crash your system.
  • A more important problem is in the security area. If you are like me, and sharing the same sub directory structure between the HTTP and FTP servers, and if you have anonymously writable directories, somebody can just upload an HTML file there with the absolute includes for sensitive files on your system and: all your secrets are no secrets anymore. Therefore, this version has two ways to deal with this problem:
    • http absinclude [on|off] command, with off as default.
    • Access authorization feature. I strongly recommend making all ftp incoming directories http inaccessible.
    • This server is to be seen as extremely experimental. No responsibilities accepted for any possible damages.

HOW TO MAKE:

• Get a copy of the standard JNOS distribution.
• Get www.zip via http or, via gopher or, via ftp.
• First unzip jn111x4.zip, then www.zip onto it. Modify the config.h and the makefile, and then make.

COMMENTS:

• Follow this link to see the contents of www.zip and some of the features of this server implementation.

• There is an 8088 executable on this server which I made using this config.h. I am not so sure if it leaves enough memory to be viable, though. The best is to make your own version with just the features you really need.

• I have also added attribute <file> <H|R|W|S> to Jnos. This one sets the DOS file attributes of a file. Eg. "attribute autoexec.nos HSR" would make autoexec.nos hidden, system, and read-only. "W" corresponds to DOS "normal" attribute and is exclusive with the rest. It is handy to hide files for remote sysops like me. If you don't want it, just undef ATTRIB in the config.h.

• The best information and support for general JNOS questions can be found at the NOS-BBS@hydra.carleton.ca mailing-list. Please, click here to find out more about the NOS-BBS mailing-list.

• If you rather prefer the old version of the HTTP server, then you should take this http.c and this gopher.c files and use them instead of the the ones in the www.zip archive.

• Disclaimer: This package carries no warranties whatsoever, explicit or implied. I cannot be held responsible for any damages, physical or otherwise, it might do to you and your data and computer and cat, and wife, ... You got the idea I guess ;) Other than that, I hope you will enjoy it.

...Retour à la page d'accueil