Apache and Wordpress with a Java applet. How to fix?

Can't get the file path working properly with a Java applet

[need2know]

I am going in circles on this problem.

My site uses a Java applet inside a Wordpress post.

The files required by the applet are hardcoded into
the applet and causes a 404 error.
The applet has a codebase of "/pages/"
WP uses a RewriteBase of "/pages/"
WP is installed in "mysite.com/pages".

Some sample GETs that cause errors are:
"GET /pages//pages/logo.gif"
"GET /pages/pages/logo.gif"
"GET /pages/2010/08/pages/images/event_name/event_photos.jpg"
"GET /pages/wp_category/pages/images/event_name/event_photos.jpg"

Is it possible to use htaccess to fix this problem?

My most current attempt is this:
RewriteRule ^pages.+pages/(.*)$ pages/$1

My thoughts are:
Start with "pages" and have one or more character before
the next "pages/". Then capture the rest of the path into $1.
Rewrite to "pages/" and the rest of the path with $1.

But the log still shows GET attempts for:
"/pages/pages/rest_of_path..."
and the error log shows that the redirect limit was exceeded.

The files do indeed exist at:
www.mysite/pages/logo.gif and
www.mysite/pages/images/...

Suggestions?

[jdMorgan]

The root problem is that the applet is apparently using page-relative links. If possible, modify that code to use server-relative links -- that is, add a slash to the beginning of each URL-path that it requests.

Keep in mind that it is the browser that resolves relative links, using the address that it currently "sees" in its address bar. Since the browser does not know about internal rewriting, using a page-relative link results in an incorrect URL request. We see this problem all the time in this forum, and the solution is to use server-relative or full-URL links and "includes".

If modifying the applet is not possible, then you will need to add an [L] flag to your RewriteRule, and be careful about the order of your rules and the location (which .htaccess file) you install this new rule in; Both can affect whether it functions properly.

Jim

[need2know]

The path is passed into the Java applet with:
<PARAM NAME=LogoImage VALUE="/pages/logo.gif">
The code inside the applet is beyond my ability.

The htaccess file is located in the web root
(above the /pages directory) and the rewrite rule is
the first rule in the file with an [L] flag.

This is a clip from the rewrite log at the first
mention of logo.gif:

add path info postfix: /var/www/pages/pages -> /var/www/pages/pages/logo.gif
strip per-dir prefix: /var/www/pages/pages/sapplet3.gif -> pages/pages/logo.gif
applying pattern '^pages.+pages/(.*)$' to uri 'pages/pages/logo.gif'
rewrite 'pages/pages/sapplet3.gif' -> 'pages/logo.gif'
add per-dir prefix: pages/sapplet3.gif -> /var/www/pages/logo.gif
trying to replace prefix /var/www/ with /pages/
strip matching prefix: /var/www/pages/sapplet3.gif -> pages/logo.gif
add subst prefix: pages/sapplet3.gif -> /pages/pages/logo.gif
internal redirect with /pages/pages/logo.gif [INTERNAL REDIRECT]

All looks good until line 6:
"trying to replace prefix /var/www/ with /pages/"

Which if responsible for that line? Browser, WP, Java, Apache?

[jdMorgan]

Your rewritelog seems to show that you've added code to "patch" this problem.

My point is that you should not attempt to correct these bad URLs, because even if you serve the correct files, the URLs are still bad.

Instead, go back to your original code set-up, and then test and examine the access log, the error log, and the rewritelog. This will simplify matters greatly.

Either your links are wrong, the applet is poorly-coded, or you've got errors in your .htaccess file(s). There is no use complicating matters by adding a work-around until it has been determined that a work-around is the only choice... That's because it is the worst choice, only to be used if the error is in code that you cannot modify.

Note that WP's use of RewriteBase in their 'standard code' is a mis-application of that directive. It is one of several problems typical of their code. It might be the root cause of this problem, but since I haven't seen all of the code relevant to these request, I can't tell.

Jim

[need2know]

On my development site I have tried to strip down to the bare minimum needed. One WP post, one use of the Java applet, and basic htaccess file.

RewriteEngine on
Options +SymLinksIfOwnerMatch -MultiViews -Indexes
RewriteBase /pages/
RewriteCond $1 ^(pages/index\.php)?$ [OR]
RewriteCond $1 \.(gif|jpg|ico|css|js)$ [NC,OR]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*)$ - [S=1]
RewriteRule . /pages/index.php [L]

All is good on the front page of WP. However, when I click on the archive link the Java applet fails to produce the photo.
In the applet:

codebase = "/pages/"
File name : <PARAM NAME = LogoImage VALUE = "logo.gif">

The rewrite.log has:

add path info postfix: /var/www/pages/2010 -> /var/www/page/2010/08/logo.gif
strip per-dir prefix: /var/www/pages/2010/08/logo.gif -> pages/2010/08/logo.gif
applying pattern '^(.*)$' to uri 'pages/2010/08/logo.gif'
RewriteCond: input='pages/2010/08/logo.gif' pattern='^(pages/index\.php)?$' => not-matched
RewriteCond: input='pages/2010/08/sapplet3.gif' pattern='\.(gif|jpg|ico|css|js)$' [NC] => matched
pass through /var/www/pages/2010

The access.log has:

/var/www/pages/2010 404#GET /pages/2010/08/logo.gif HTTP/1.1#

The error.log has:

File does not exist: /var/www/pages/2010

To me it seems that the fix needs to be inside WP. Currently I am not knowledgeable enough to accomplish that. (But, learning every day!)

Can a "dirty" fix be implemented via htaccess until I am able to correct it properly inside the other code?