a Fuseki Jetty server behind an Apache HTTPd proxy-pass

[peutch]

Version

4.8.0 and after

Question

Hi,

For a long having Fuseki Jetty server behind a proxy-pass was possible up to version 4.7.0. For this, I am just using a extra FusekiCmd2.java (based on FusekiCmd.java little patched) that sets the jettyServerConfig.contextPath property using a extra command line option.
This currently works almost nicely, I did not check for all cases but it is working for what we expected to provide.

Now trying to upgrade to newer Fuseki versions seems to break this.
Regarding the new version 5.0.0, doing the same trick is not a problem regarding Java side. But at runtime, some provided page URLs have mostly references to "/static/...." and not "/fuseki/static/..." for CSS and JS.

Is there a possible solution?

Many thanks,
Patrice

[kinow]

Not sure if it's something on the Jena side, or something on the server/proxy-pass.

I compared the JS part after syncing the repo, git diff jena-4.10.0..jena-5.0.0 -- jena-fuseki2/jena-fuseki-ui/, but didn't find anything that seemed to cause this. You mentioned you have a patched FusekiCmd2.java, maybe you can diff other files like git diff jena-4.10.0..jena-5.0.0 -- jena-fuseki2/jena-fuseki-core and try something on the servlet side to see if reverting something makes it work again for you - I am using Jena from the IDE or containers, so I do not have this issue nor anywhere to test it.

[peutch]

My trouble is for any version greater than 4.7.0 (the > was removed in version section), so doing a git diff jena-4.7.0..jena-5.0.0 -- jena-fuseki2/jena-fuseki-ui/ may be more useful.
There is a assetsDir: 'static' in jena-fuseki2/jena-fuseki-ui/vite.config.js, this is the cause?
If there is a way to have the paths of remote resources being relative (like static/... and not absolute (/static/...), perhaps this could help?

[afs]

Hi @peutch

(Fixed the version. I misunderstood the entry. So it's all versions 4.8.0 and later?)

Is the proxy pass changing the URLs?

I don't know about relative/absolute naming, sorry. What may help is copying the static assets to the expected file path "webapp/fuseki/static/".

[peutch]

Hi @afs,

Yes, in fact I did not tried 4.8.0 but 4.9.0, 4.10.0 and 5.0.0.

Currently there is just this following in the virtualhost configuration:

<Location /fuseki>
	ProxyPass http://localhost:3030/fuseki
	ProxyPassReverse http://localhost:3030/fuseki
</Location>

and the Fuseki Jetty server sets to contextPath='/fuseki'.

You can access here to our current «working» setup if it helps to see:
https://www.imgt.org/fuseki/

[afs]

I have a modified Fuseki-webapp which has a command line --contextPath.
I don't have a ProxyPass setup but the description above isn't changing the inbound URL paths.

In index.html, I changed "/static" to "static", "/favicon.ico" to "favicon.ico" and things seem to work.

@peutch - would you be able to try that in your setup?

@kinow - where does final index.html come from?

The webpack to vite change Jan2023, just after 4.7.0, added the index.html in the source tree. But the (after /static" to "static" experiment) also has

    <script type="module" crossorigin src="static/index-SkN_20H7.js"></script>
    <link rel="stylesheet" crossorigin href="static/index-hhGzt_hl.css">

which looks is generated.

vite.config.js has assetsDir: 'static'

( I vaguely recall we had this or similar problem before)

[kinow]

@kinow - where does final index.html come from?

You can yarn build, and the final version should be in target/webapp/public (see build.outDir in vite.config.js).

[afs]

@kinow - Ok but how does the build know to put in src="/static and href="/static. Looking for a way to control control the content.

The idea of editing the generated file after its built ... is a bit risky!

[kinow]

The idea of editing the generated file after its built ... is a bit risky!

Agreed!

The webpack to vite change Jan2023, just after 4.7.0, added the index.html in the source tree. But the (after /static" to "static" experiment) also has

This might explain it ☝️

@kinow - Ok but how does the build know to put in src="/static and href="/static. Looking for a way to control control the content.

We can control that with the base setting in vite.config.js (we don't have it, but it can be added right at the top - https://vitejs.dev/guide/build#public-base-path

diff --git a/jena-fuseki2/jena-fuseki-ui/vite.config.js b/jena-fuseki2/jena-fuseki-ui/vite.config.js
index 4c8bee28c9..f6374b7596 100644
--- a/jena-fuseki2/jena-fuseki-ui/vite.config.js
+++ b/jena-fuseki2/jena-fuseki-ui/vite.config.js
@@ -23,6 +23,7 @@ const path = require("path")
 
 // https://vitejs.dev/config/
 export default defineConfig({
+  base: '/something/static/',
   plugins: [
     vue(),
     istanbul({

Or to test without modifying files:

$ yarn build --base=/something/static/
$ python3 -m http.server -d target/webapp 8000

Visit http://localhost:8000, and the files included in index.html should be going to something like http://localhost:8000/something/static/static/index-PkYBuHRI.js.

[kinow]

Haven't looked at the pre-vite git files, but I suspect we had / as base before? Not sure if simply adding that to base and re-building would work for the vanilla case, and to the scenario described in this issue

[afs]

The problem is that we don't know the "/something" at build time. The "something" is chosen later e.g. by @peutch.

If a relative base base: 'static/', causes the code works we should be good.

Would I be right in thinking vite.config.js assetsDir: 'static' is file path and not related to the generated URLs?

That gives:The problem is that we don't know the "/something" at build time. The "something" is chosen later e.g. by @peutch.

If a relative base base: 'static/', causes the code works we should be good.

PS vitejs/vite#5081 :: setting is './'

[kinow]

Would I be right in thinking vite.config.js assetsDir: 'static' is file path and not related to the generated URLs?

Yes, a directory/path. The default value is assets, from vite docs:

Specify the directory to nest generated assets under (relative to build.outDir. This is not used in Library Mode).

PS vitejs/vite#5081 :: setting is './'

./ as base would make sense, it should work for / and other base/context paths. The dafult is /, and they have this in their docs (love Vite docs):

Base public path when served in development or production. Valid values include:

Absolute URL pathname, e.g. /foo/
Full URL, e.g. https://foo.com/ (The origin part won't be used in development)
Empty string or ./ (for embedded deployment)

I think the last option is worth testing. Let me prepare a PR so that we can try that.

[peutch]

Hi,
I can confirm that it works nicely with #2396.
Many thanks!

[kinow]

Hi, I can confirm that it works nicely with #2396. Many thanks!

@peutch I was going to test it with Docker but as you tested it will save us time and I think we can review/merge that one.

Thanks a lot for confirming it works!

[afs]

There's now a --contextPath= for the command line.

[peutch]

Hi,
Just for you to know:

• using the main branch is breaking again something (http://localhost:3030/fuseki does not serve index.html and forcing http://localhost:3030/fuseki/index.html goes wrong).
• using e1e9bf4 and just cherry picking 2f3a293 is working as expected.
  Probably one commit in between breaks something. One of the dep updates in 3a09ec5? Didn't tried to bisect.

[kinow]

Hi, Just for you to know:

* using the main branch is breaking again something (http://localhost:3030/fuseki does not serve index.html and forcing http://localhost:3030/fuseki/index.html goes wrong).

* using [e1e9bf4](https://github.com/apache/jena/commit/e1e9bf40afc9860776acaefc55e90a4744f374e0) and just cherry picking [2f3a293](https://github.com/apache/jena/commit/2f3a2930b9e673ca0f1f9495ce0e7f89b04ff5ea) is working as expected.
  Probably one commit in between breaks something. One of the dep updates in [3a09ec5](https://github.com/apache/jena/commit/3a09ec5ebefca00fb3da57b123951c272ef84f01)? Didn't tried to bisect.

Thanks for letting us know! I think we ought to add a test for this so we don't break it again. Will create an issue for that. Thanks!

[kinow]

Done: #2419