Pssst...Ferdy is the creator of JungleDragon, an awesome wildlife community. Visit JungleDragon

Domino HTTP error...I could use your help »

FERDY CHRISTANT - MAY 14, 2008 (06:48:22 PM)

I know it's been a while since I last blogged about Lotus Domino, but I could surely use your help fixing an odd problem. Today, Bill (who hosts my blog) pointed me out to some odd exceptions on the server:

14/05/2008 10:21:42 HTTP Web Server: Unknown Command Exception [/fchristant/production/fdm.nsf/articles/DOMM-6NDQEJ/scripts/scripts /script/scripts/scripts/scripts/scripts/scripts/ scripts/scripts/script/script/script/ script/script/script/script/script/scripts/script/sortabletable.js]

There's hundreds if not thousands of these entries, and I'm stuck tracking down the cause of the problem. Allow me to share what I know so far:

To start with, this is a non-destructive error, I was not even aware it was there. Nevertheless, I would still like to fix it.
The NSF being referenced is in fact my blog, the next part is the view, and then the document in the view. Next follows the problem: an almost endless sequence of "scripts" path elements in the URL.
Inside my blog are two Javascript script library design elements called "scripts/events.js" and "script/sortabletable.js"
The javascript libraries contain perfectly common javascript, no weird things there. They are referenced from one place in the design of the database: the HTML header subform, which is included on every page.
The HTML header subform has a base url field that computes tot this:

<base href="http://www.ferdychristant.com/blog/" />

Next, the javascript libraries are referenced from the same subform using the following relative URLS:

<script type="text/javascript" src="scripts/events.js"></script>
<script type="text/javascript" src="script/sortabletable.js"></script>

These references work fine, and they are the only place in the design where such a reference to the javascript libraries are made.
A search in the design reveals that there are no design element naming conflicts.
The rendered HTML source nowhere results in requests with the scripts directory repeated
The problem is not limited to a single view or document, it happens across views and documents
The problem seems to occur on pretty much every page request, given that the log file is pretty much dominated with this error

In summary, I still do not have a clue where this odd exception, or the request that leads to it, is coming from. Here's to hoping someone in the community is able to help out. Thanks in advance!

Lotus Domino

Share |

Comments: 5

COMMENT: CHRIS TOOHEY

MAY 14, 2008 - 07:25:09 PM

comment » Just a thought here - although this shouldn't matter I'd think. Can you create a dummy element called "script|scripts" or alias your index.html/main page control design element? «

COMMENT: FERDY

MAY 14, 2008 - 07:47:47 PM

comment » Chris,

Thanks for thinking along. I should have been more specific. The error appears in the log not for every page, but for every single entry that gets opened. So it does not occur when ferdychristant.com is opened (where the last 5 entries are displayed), but it does occur when an individual document is opened (either a blog entry or article).

I'm not sure how an alias would relate to the repeated scripts directory, maybe I'm missing something. Care to explain? «

COMMENT: MICHAEL GOLLMICK

MAY 14, 2008 - 19:58:43

comment » I have seen such mesages before when I was playing around with redirections and did some stupid mistake. In the end the server was generating redirections for every request and so the URI was prolonged for every request. normally the browser is then stopping that after a ceratin time with a message "too many redirections". Unfortunately the URI was exceeding the 2k/4k limit before that event and so the server got a GET request larger than its maximum size wich leads to such messages on the log...

The only thing I have for you, is: find the reson for that redirection and eliminate it - and that's probably not as easy as it was with my DSAPI-filter that time «

COMMENT: TOMMY VALAND

MAY 14, 2008 - 20:10:53

comment » I think that the problem is that when you open an article, you open a view/you use relative urls to the scripts.

script/sortabletable.js is under

/fchristant/production/fdm.nsf/script/sortabletable.js

not

/fchristant/production/fdm.nsf/archive/script/sortabletable.js

This gives an error-page on this URL:

http://www.ferdychristant.com/fchristant/production/fdm.nsf/archive/script/sortabletable.js

Which again cointains a relative reference to script/sortabletable.js, and you have started an evil circle..

Simple solution, use absolute path to the JS: «

COMMENT: FERDY

MAY 14, 2008 - 09:14:42 PM

comment » Michael,

Yeah I thought about that, but my substitution rules have been in place for years and they are extremely simple and seem to have the correct syntax.

Tommy,

Thanks! That did seem to solve the problem. So far no more errors have occurred in the log. Where did I go wrong:

I assumed that by having a base href in place, all subsequent links would be relative to that. The truth is that this only applies to document links, and not the links in the header section (css, scripts, etc). Strangely enough the problem does not occur for my CSS page links, which are still relative. Quite a mystery, isn't it?

Anyway, thanks for your responsive help, this community is still awesome. I will obviously include this fix in an upcoming version of Blogo (this blog template).

Cheers! «