From: SMTP%"VMSGopher-L@trln.lib.unc.edu" 31-MAY-1994 10:19:45.27 To: EVERHART CC: Subj: Re: GIF Files with the CERN HTTPD Server X-Listname: Gopher for VMS implementation and testing Warnings-To: <> Errors-To: postmaster@trln.lib.unc.edu Sender: postmaster@trln.lib.unc.edu Date: Sun, 29 May 1994 16:27:36 -0400 (EDT) From: Foteos Macrides Reply-To: VMSGopher-L@trln.lib.unc.edu Subject: Re: GIF Files with the CERN HTTPD Server To: VMSGopher-L@trln.lib.unc.edu Message-Id: <01HCX0QRTS82000PJA@SCI.WFEB.EDU> X-Vms-To: IN%"VMSGopher-L@trln.lib.unc.edu" X-Vms-Cc: MACRIDES Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT wrigley@scwrc.scwrc.scarolina.edu wrote: >Thanks to this newsgroup and Fote I have gotten my HTTPD server up and >running on a test port. > >However I have run into a strange problem with .gif files. > >These files are set up as anchors in the origional test html. >[...] >

>[...] >The server accesses the html file fine but gets an error num -501 when >attempting to access the .gif file in the same VMS dirtectory as the html >file with the same VMS protections. > >Winmosaic produces an errorbox message. HTAccess: Error accessing >"http://foo.bar:8001/wild/stseal.gif": Err Num -501 > >Note this is not the correct URL, I am not quite ready to publish this >info. But real soon now! > >My current conf file >[...] >map /www/* /WWW_Root/000000/* >map / /WWW_Root/000000/Welcome.html >pass /WWW_Root/000000/* >pass /www/wild/* >pass /www/sercc/* >[...] Rick, You're getting closer, but... A) You still haven't put together the two layers of symbols/logicals that are used by the httpd before it translates to VMS path specs and ultimately attempts to access a file or execute a script. B) You apparently don't have the VMS logicals for your paths defined properly or don't have your data tree set up the way you intended (see below). Since a number of people are having problems with this, and want to maintain both httpd and gopherd servers with coordinated data trees, perhaps it would be worthwhile to summarize and illustrate the principles and rules here, though I don't know if this is an appropriate group for an extensive discussion. (Save this if you don't read it now, instead of emailing me later, when you have questions it answers, OK?) (A) --- The slash-separated strings in URL's *look* like Unix path specs, but that's *not* what they are. They are a "symbolic hierarchy", which could be used in reference to *anything* which has a hierarchical underlying structure. When you do use it in reference to a Unix or VMS path spec, your configuration file should include: (a) "map"s for converting the URL's symbolic hierarchy to one which can be translated into Unix or VMS path specs, and (b) "pass" rules for informing the httpd that the converted hierarchy is acceptable (i.e., not pointing somewhere which is not intended to be accessed by the httpd). On VMS, the maps should recast the URL's symbolic hierarchy into one which begins with a device name. The device name could be physical or logical (in VMS terms), but *must* be a device name, for the subsequent translation to VMS path specs to work. You have, as I recommended, defined WWW_Root as a concealed device logical, equivalently to Gopher_Root for the gopherd (they could, in fact, be the same data tree root, or one could be a limb of the other's data tree). These configuration file entries: map /www/* /WWW_Root/000000/* map / /WWW_Root/000000/Welcome.html pass /WWW_Root/000000/* (a) allow URL's to use /www/ as a substitute for /WWW_Root/000000/ e.g., /www/foodir/foo.html will be converted to /WWW_Root/000000/foodir/foo.html which is accepable by your pass rule, and will therefore be sought on VMS as WWW_Root:[000000.foodir]foo.html (b) allow URL's to access WWW_Root:[000000]Welcome.html via a NULL path, equivalently to accessing a gopherd's root directory via a NULL Path= field in a gopher tuple. SO... here's your primary problem:

means GET the image "referenced" as /wild/stseal.gif but you have NEITHER a map NOR a pass rule for /wild/* and the httpd is CORRECTLY rejecting that. If it HAD passed as /wild/stseal.gif VMS would seek it as wild:stseal.gif which I'm sure is nonsense on your system. ALSO, your pass /www/wild/* and pass /www/sercc/* are superfluous, because your map /www/* WWW_Root/000000/* will cause /www/wild/foo.gif to become /WWW_Root/000000/wild/foo.gif and /www/sercc/foo.gif to become /WWW_Root/000000/sercc/foo.gif and the LATTER representions will be checked for a pass rule. They WOULD pass, because they meet the /WWW_Root/000000/* pass rule, but you don't have /www/wild/stseal.gif in your IMG tag, nor /WWW_Root/000000/wild/stseal.gif Until you get the "hang" of it, you are better off thinking your way "back" from the actual VMS path specs. If you have WWW_Root:[wild]stseal.gif on your computer, that is: /WWW_Root/000000/wild/stseal.gif in httpd symbols. Do you have a pass rule for that? YES: pass /WWW_Root/000000/* Do you have a map for specifying the file sybolically with a URL that is less cumbersome than /WWW_Root/000000/wild/stseal.gif? YES: map /www/* /WWW_Root/000000/* so your URL can be /www/wild/stseal.gif Is there an even better map you could add to your configuration file, to permit yet more convienient, meaningful symbols in your URL's? YES: map /wild/* /WWW_Root/000000/wild/* which is encompassed by your: pass /WWW_Root/000000/* so then you *can* use:

which will be mapped to: ^^^^^^^^^^^^^^^^ /WWW_Root/000000/wild/stseal.gif and be sought as: WWW_Root:[000000.wild]stseal.gif which is equivalent to" WWW_Root:[wild]stseal.gif In this way, all of your *WILD* images could be referenced "intuitively" via /wild/foo.gif URL's, and the httpd server and VMS operating system will not go wild trying to find them 8-). Is that where the image actually is? E.g., if you use $ DIR WWW_Root:[000000.wild]stseal.gif does DCL list it, or return an error message? Does your server have read access to the file (via the operating system's protection/ACL checks, not just the httpd server configuration file's "rules")? (B) --- I can get the image from your server by using: http://:8001/www/www_data/wild/stseal.gif or ^^^^^^^^^ http://:8001/WWW_Root/000000/www_data/wild/stseal.gif but ^^^^^^^^^ this doesn't work: http://:8001/www/wild/stseal.gif whereas I CAN get your Welcome page via http://:8001/www/Welcome.html which implies you do not have the VMS logicals defined properly, or have not set up your data tree as you intented. (A), above, will apply when the VMS definition for the data root is correct: $ DEFINE/SYST/EXEC/TRAN=CONC/NAME=NO_ALIAS "WWW_Root" device:[directory.] and when your map/pass rules correspond to your actual data tree. CSwing is extremely helpful in this situation. It gives a graphic representation of your data tree, which you can generate by using your VMS logicals for it, so you can "see" if they reference what you intend, and whether the tree is "really" set up the way you intended, or kinda remember having set it up. gopher://sci.wfeb.edu:70/11%5b_FileServ._CSwing%5d ftp://narnia.memst.edu/ (C) --- Once you *do* get the "hang" of it all, the map/pass mechanism is a really powerful combination of symbolic representations, because you can set it all up such that your URL's make *SEMANTIC* sense to the users and when you write them into your HTML, and the httpd software will convert them to symbols which VMS can handle properly. But until you, the administrator, grasp the precise *SYNTAX* for the computer, which doesn't have a human's intuitive abilities, and won't be able to guess what you intended instead what you literally instructed it to do, its SOooooooo confusing ;(. map Symbols_Meaningful_to_ANY_Human Symbols_Meaningful_to_a_mere_Computer pass the_Symbols_for_the_Computer http://Meaningful.Host.Name[:port_Number]/Symbols_Meaningful_to_ANY_Human In a GOPHER TUPLE you have: Name=Symbols_Meaningful_to_ANY_Human Port=port_Number Host=Meaningful.Host.Name Path=Symbols_Meaningful_to_a_mere_Computer <-This is opaque, and need not be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Symbols_Meaningful_to_ANY_Human because that's "covered" by the Name=Symbols_Meaningful_to_ANY_Human. NOTE THAT, in the current protocol for gopher:// URL's, it's the opaque, Path= field that's used, with awful conseqences: Do you see how impossible to remember, unlikely to be transcribed correctly, and basically useless to a human, the gopher:// URL for CSwing on our gopher server is, above. That's why it's worth the bother to master use of map/pass rules for your http:// URL's. The current working draft RFC for Gopher+ URL's would simply tack on the "extra stuff" to that "base" path, and escape (convert to %## hexadecimal equivalents) the non-text or otherwise "illegal" characters in the "extra stuff" (e.g., tabs, spaces, and the open- and close-square-brackets in VMS path specs). If that indeed becomes the standard, the Gopher+ URL's will become so unmanageable, that I doubt anyone will bother to implement Gopher+ on the Web ;(. I hope it doesn't turn out that way, but... Fote ========================================================================= Foteos Macrides Worcester Foundation for Experimental Biology MACRIDES@SCI.WFEB.EDU 222 Maple Avenue, Shrewsbury, MA 01545 =========================================================================