Redirect "unable to find web xxx" Messages

[Fuzzmaster]

Anyone know an easy way to redirect all the "unable to find web xxx" error messages? Or a reason not to do this? It appears to me that it would involve several edits in the "/src/web/objects" area and a few re-compiles...

I have custom error messages set up both in IIS and via the WsCusErr.txt file handling most everything else. I even have direct/improper requests for the scripts directory redirecting, but it seems I have no ability to intervene once that messenger has the request in it's grubbies.

Examples of working error redirects:

http://host/scripts/ -> http://host/scripts/messenger/index.htm
http://host/nonpage.htm -> http://host/err/err_404.htm

Examples of what I'm looking for:

http://host/scripts/messenger?nonservice -> http://host/err/err_501.htm
http://host/scripts/messenger/ -> http://host/scripst/messenger/index.htm
http://host/scripts/messenger/nonpage -> http://host/err/err_404.htm

Be kind, while I'm still pouring through the Progress Library looking for better solutions, I've yet to find any.

 

[Fuzzmaster]

Anyone? Seems like this should be incredibly simple thing to fix. Just google ""Unable to find web object file"" and enjoy scrolling through page after page of Webspeed servers all with an apparent inability to do something as simple as displaying a 404 error. It's embarrassing.

Perhaps something on the CGI side?

 

[agnaldo.macedo]

See (and customize)
​

PROCEDURE run-web-object

in /dlc/src/web/objects/web-util.p

This message comes from there.
​

 

[Fuzzmaster]

agnaldo, You're #$%#@% Awesome!

What I Did (Based on your mighty fine advise)

1. Modified "/src/web/objects/web-util.p" (See Modifications Made).
2. Compiled a new "web-util.r".
3. Replaced both copies of the existing "web-util.r" (/tty... & /gui...).
4. Restarted the broker and enjoyed.

Modifications Made

A few small changes to the "showErrorScreen" Function did the trick:

Before:

DYNAMIC-FUNCTION("output-content-type" IN web-utilities-hdl,"text/html").
{&OUT} "<BR>" cErrorMsg "<BR>".

After:

  /* ##### Redirect to Error Handler - JS 2009.03.02 */
  OUTPUT-HTTP-HEADER ("Status":U, "500 Internal Server Error":U).
  OUTPUT-HTTP-HEADER ("Location":U,  "/err/wse.php?errMSG=":U + url-encode(cErrorMsg, 'default')).
  OUTPUT-HTTP-HEADER ("", "").

Question:

Any reason why redirecting like this may become an issue? I ran a few break tests and it seemed to hold up fairly well; however, I'm worried about the possibility of some other content getting to the headers first and spoiling the redirect.

Once again, thanks a ton... while I might have eventually found this, it's nice to have a little hand now and again!!

 

[agnaldo.macedo]

Remember to make a copy when it update the version of Progress.
​

 

[webguy]

Anyone? Seems like this should be incredibly simple thing to fix. Just google ""Unable to find web object file"" and enjoy scrolling through page after page of Webspeed servers all with an apparent inability to do something as simple as displaying a 404 error. It's embarrassing.

Perhaps something on the CGI side?

Lol on the Google thing. I agree. Although you can modify web-util.p its pretty crude. Webspeeds great but Progress doesnt pay it much attention these days. They could do so much more. Its really frustrating coming from something like PHP.