Ohai there, it seems like my caddyfile for Taiga is not fully working.
When joining the baseurl (tree.domain.de), everything is just fine,
i can navigate to everywhere without trouble.
But when i want to navigate to my project directly/hit f5, i get a 404 by caddy.
But it works while navigating through taiga just fine, i can do everything there.
The issue only appears when i refresh the page / use a directlink to something.
After having a look at your link, too, the nginx config has try_files $uri $uri/ /index.html; which I’m not sure if you want to try to emulate:
rewrite {
to {uri} {uri}/ /index.html
}
Whoooot? This did the trick
I thought this is just some eyecandy trick which is not needed with caddy o.O
My hunch is that while navigating in app, clicking links produces requests to /api/v1/projects/by_slug rather than /projects. Since /api is proxied, this works fine, but because it shows the client the /projects URL, we have problems when manually refreshing or navigating to it.
I also assume that when rewritten to index.html there is some scripting going on to check the requested project and finish up by making the correct /api endpoint call. I’ve seen this done plenty of times with .php files, but this is the first time I’ve seen it done with a plain .html file.
As you can see, it can be very important when dealing with dynamic sites & scripted apps, especially when pretty URLs are involved. With a rewrite like that you can serve an entire app and all its content out of one .php file.
Bummer! Guessing theres a script not loading now. Not sure how, adding that rewrite didn’t invalidate any previous request paths, merely added a fallback (as you can see it tries the plain {uri} first, which is exactly what the initial request is). Can you find out exactly which request is failing to produce the required javascript?
No, i guess not…
I’ve got: /api/v1/projects] read tcp 127.0.0.1:36672->127.0.0.1:8001: read: connection reset by peer
Which was odd because the app was listening (maybe it was the refresh button - it happened again) - now i only get /index.html?slug=milan-project HTTP/2.0" 200 25995
And the page stays somewhat blank.
…i guess that it takes ages to load is not only caused by my bad internet.
Your suggestion to change it to {path} sadly didn’t made any difference.
So the API gave Caddy the middle finger to that particular request, which seems a little odd.
At this point I’d probably see if I could swap in nginx and try this particular request again to determine if it’s the API backend being weird or, uhh, something off in Caddy’s proxied request.
I’ll admit that now is usually the point where I’d give up, grab a Docker for it and just proxy it.
Well - setting up taiga was not “that” big fun - at least on archlinux - because the deps are only documented for debian/-based :
So i tried two docker images but they where incomplete - also i figured some things out at the same time and decided to get this thing to run without docker - with success … except…
If there is really no solution i may really try to trick with nginx.
Fixed by if {path} not_match ^/api
From this thread.
Thanks again - i will mark this post here as solution since i am afraid of confusing people in the future when i mark your suggestion without any hint about the if as solution, i hope you understand this.