It's possible for us to make the requested changes and we may indeed do so, but this will not happen right now, because we are currently in the final stages of testing the upcoming FoxWeb 3 release. On the meantime you can do the exact same thing in fw_enter.prg. All you need to do is modify the value of Request.PathInfo to point to the correct location. I think that the following will work in your situation, but I'm not 100% sure:
IF '@/DB/' $ Request.PathInfo Request.PathInfo = STRTRAN(Request.PathInfo, '@/DB/', '@') ENDIF |
The above would convert a URL such as the following:
To:
Obviously this is still using the old syntax, but it should still work fine with version 2.6. If you want you can modify the above algorithm to place the folder name (in this case 'pub/') right before the procedure name:
Obviously the preferred syntax utilizes script mapping and is much cleaner:
FoxWeb Support Team
support@foxweb.com email |
Sent by David Hempy on 03/30/2004 02:43:53 PM:
That makes sense as to why the 2.x behaves differently than the 1.x. You make some good suggestions. I like the option 2, and will probably go that route.
Let me ask another question... What it would take to update the backward compatibility routines in FoxWeb 2.x to recognize URLs like these? I'm guessing it is searching for "@?/" (where ? is a single-character wildcard) or similar to change to a different parsing algorithm. Could that test be modified to also detect "@/", or a second test be performed?
If that could be folded into v2.6a or something, that would save me a minumum of a half-week of work. It could also preclude other legacy FoxWeb customers finding obstacles to upgrading to 2.x
If this is not possible, I am glad to have the options you spell out below and will certainly take advantage of them...but I'm really hoping that your engineers will find this a trivial fix and can release a patch or update.
-dave
Sent by FoxWeb Support on 03/30/2004 12:04:45 AM:
It is true that the officially supported syntax changed slightly between FoxWeb 1.X and 2.X. With FoxWeb 1.X the syntax was /ProcName@ScriptPath/ScriptName, while with FoxWeb 2.X it is
/ScriptPath/ProcName@ScriptName. The reason for this is that the old method did not work with script-mapped URLs on most servers.
To maintain compatibility FoxWeb 2.X still supports the old syntax, so this is not your problem. I think the problem is related to the leading slash in @/db/pub/. FoxWeb 1.X treated this slash as to mean that the db folder was under the drive root (for example c:\db), while FoxWeb 2.X simply ignores it and looks for the db folder under the FoxWeb Program Root (for example c:\Program Files\FoxWeb\Progs\db). The FoxWeb documentation never stated how a leading slash would be interpreted in this case, but it seems that the behavior has changed with version 2.
I can recommend two possibilities:
a) The easiest option in the short term would be re-create the old directory structure under the FoxWeb Program Root. For example, you could move your \db folder with all its contents to your new Program Root. This should work, but it is not recommended, because it will continue the utilization of a URL syntax that is not officially supported in FoxWeb 2.
b) My preferred solution is more difficult in the short run, but I believe it will pay off in the future:
- Modify all your scripts and static files so that they use the new script-mapped syntax, with the ScriptPath at the beginning of the URL.
- Modify the authorization code in fw_enter.prg so that it can parse the new URLs.
- Modify fw_enter.prg so that it detects old style URLs and returns a page indicating to users that the URL has changed, so they need to modify their bookmarks and notify the administrator of the site that lead them there. You can also provide a direct link to the correct URL. An added bonus would be for the code to store the value of Request.ServerVariables('http_referer'), so that you can notify administrators of remote sites yourself.
FoxWeb Support Team
support@foxweb.com email |
Sent by David Hempy on 03/29/2004 09:46:58 PM:
Thanks for the reply to "Trying to use.FWX with Netscape Server". That fixed one of the issues. I have gotten .fwx files to be processed by FoxWeb. I'm still getting some errors there, but I think I can see my way through those.
Of greater concern is the formation of URLs to our existing scripts. We've got eight years' worth of systems that use URL's of this format with FoxWeb 1.29:
http://www.dl.ket.org/cgi-pub/foxweb/PreviousWork@/db/pub/pub?courseid=PHYS
"/foxweb/" is just foxweb.exe renamed without the extension. I did that out of paranoia back in '97 or so because seeing .exe in the URL just made me nervous. Ahh...youth. Anyway, I can fix that issue one way or another. (at worst, a web server redirect) I expect I can do this in such a way that existing links will work.
"PreviousWork" is the function name in the program file "/db/pub/pub" . /db is a root folder on the hard drive.
So now I've installed Foxweb 2.6 on our edit server. The URL above does not work with this version. It seems the only way I can get that page to work is with a URL like this:
http://edit-dl.ket.org/cgi-pub/foxweb.exe/pub/PreviousWork@/pub?courseid=PHYS
(If this link doesn't work for you, that mean's I'm still experimenting with other options. You should get "Please Telephone KET", or better yet, a list of lessons)
I've left the .exe on the current foxweb.exe distribution, as it doesn't work at all without. As I said, I realize now I was kinda stupid for doing that, and I can deal with that.
What would be a MAJOR burden is the change in the logical path. In v1.x, the path to the program followed the "@". Now the docs say the script_path comes before the procedure name and "@", and and that the script_name comes after the "@". Is this correct? Or have I been doing it wrong for all these years and it just happened to work despite my ignorance?
Is there a fix for this under v2.6? I've tried setting "Full paths in URLs" both ways, and found I need it on for "/db/pub" to work. However, that still doesn't allow the old-style URL's to work.
Changing the URLs to the new syntax would introduce several problems:
- I've got code that parses the URL for access level (public, student, teacher, etc.) that authenticates users, selects appropriate templates, and decides various code branches. Most of that is centralized in fw_enter.prg, so it wouldn't be too bad to fix that. There are a sprinkling of other programs that would be affected as well...they would take a fair amount of work to ferret out.
- I'd have to change all my dynamic links to use the new syntax. Fortunately, nearly all are written by my own URL() function, so that's probably a one-stop fix.
- Links from hundreds of flat files on our site would need to be changed. That's what interns are for, I suppose.
- Links from other sites...two years from now they still would not all be fixed. This of course drives the search engine rankings. Go search Google for "German distance learning", "physics distance learning", "latin distance learning", or "humanities distance learning", etc. and you'll generally find us in the #1 slot. Search for "Distance Learning" and we're usually in the top 25. You can certainly appreciate my apprehension at changing absolutely anything that will reduce the pagerank of any of our pages.
So...is changing our URL's mandatory to upgrade to 2.6? Or have I just plain missed something in the docs? I really, really don't want to change all our URL's if I can avoid it. Even if there is a performance penalty, I'll take it. Losing backward compatibility would seriously hinder upgrading the product. That is a shame, as I'm eager to upgrade to VFP 8.0
Looking forward to your reply,
-dave
--
David Hempy
Internet Database Administrator
Kentucky Educational Television
(859)258-7164 - (800)333-9764