Caddyfile for Taiga not fully working

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.

==> /var/log/caddy/tree_access.log <==
##direct link to the project
 "GET /project/milan-project/us/5 HTTP/2.0" 404 38
## navigating to the project
 "GET /api/v1/projects?member=5&order_by=user_order HTTP/2.0" 200 1412
 "GET /api/v1/epics?assigned_to=5&status__is_closed=false HTTP/2.0" 200 26
 "GET /api/v1/userstories?assigned_to=5&is_closed=false HTTP/2.0" 200 1342
 "GET /api/v1/tasks?assigned_to=5&status__is_closed=false HTTP/2.0" 200 26
 "GET /api/v1/tasks?status__is_closed=false&watchers=5 HTTP/2.0" 200 26
 "GET /api/v1/issues?assigned_to=5&status__is_closed=false HTTP/2.0" 200 26
 "GET /api/v1/issues?status__is_closed=false&watchers=5 HTTP/2.0" 200 26
 "GET /api/v1/epics?status__is_closed=false&watchers=5 HTTP/2.0" 200 26
 "GET /api/v1/userstories?is_closed=false&watchers=5 HTTP/2.0" 200 764
 "GET /api/v1/user-storage/joyride HTTP/2.0" 200 153
 "GET /api/v1/projects/by_slug?slug=milan-project HTTP/2.0" 200 2311
 "GET /api/v1/projects/by_slug?slug=milan-project HTTP/2.0" 200 2311
 "GET /api/v1/userstories/by_ref?project=3&ref=5 HTTP/2.0" 200 915
 "GET /api/v1/tasks?project=3&user_story=8 HTTP/2.0" 200 26
 "GET /api/v1/userstories/custom-attributes-values/8 HTTP/2.0" 200 80
 "GET /api/v1/userstories/attachments?object_id=8&project=3 HTTP/2.0" 200 26
 "GET /api/v1/history/userstory/8 HTTP/2.0" 200 676
 "GET /v-1487165065370/js/maps/app.js.map HTTP/2.0" 200 2140748
  • This would be the nginx config

This is my current caddyfile:

tree.domain.de {
        tls inbox@domain.de {
                key_type rsa4096
        }
        gzip
        root /home/taiga/taiga-front-dist/dist
        proxy /admin localhost:8001 {
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Scheme {scheme}
                header_upstream X-Forwarded-Proto {scheme}
                #transparent
        }
        proxy /api localhost:8001 {
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Scheme {scheme}
                header_upstream X-Forwarded-Proto {scheme}
                #transparent
        }
        proxy /events localhost:8878 {
                websocket
        }
        log /var/log/caddy/tree_access.log
        errors /var/log/caddy/tree_error.log
}

tree.domain.de/static {
        root /home/taiga/taiga-back/static/
}

tree.domain.de/media {
        root /home/taiga/taiga-back/media/
}

kind regards!

Hi @tchncs,

I note that there is no proxy directive for the /project base URL and no more specific vhost for this path either, which leads to the question…

What’s in the file located on disk at /home/taiga/taiga-front-dist/dist/project/milan-project/us/5, and are its permissions set properly?

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 {
    if {path} not_match ^/api
    to {uri} {uri}/ /index.html
}

Edit: Added if statement as per comment further down

There is no such thing:

# l /home/taiga/taiga-front-dist/dist/                                                                                                                                                      :(
insgesamt 92
-rwxrwx--- 1 taiga caddy   542 16. Feb 11:47 conf.example.json
-rwxrwx--- 1 taiga caddy   301 17. Feb 08:39 conf.json
-rwxrwx--- 1 taiga caddy  2628 16. Feb 11:47 humans.txt
-rwxrwx--- 1 taiga caddy 76224 16. Feb 11:47 index.html
drwxrwx--- 8 taiga caddy  4096 16. Feb 11:47 v-1487165065370

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 :scream_cat:
I thought this is just some eyecandy trick which is not needed with caddy o.O

Thank you :tada:

Whups, no i’m wrong (sorry, very slow connection, i thought it will just load until it’s done).
This somewhat broke libs.js. :frowning:

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?

Actually, try changing to:

rewrite {
    to {path} {path}/ /index.html
}

real quick first and see if that fixes it.

Thanks for your detailed answer. :slight_smile:

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. :smiley:

Did i even did this right?

tree.domain.de {
        tls inbox@domain.de {
                key_type rsa4096
        }
        gzip
        rewrite {
                to {path} {path}/ /index.html
        }
        root /home/taiga/taiga-front-dist/dist
        proxy /admin localhost:8001 {
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Scheme {scheme}
                header_upstream X-Forwarded-Proto {scheme}
                #transparent
        }
        proxy /api localhost:8001 {
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Scheme {scheme}
                header_upstream X-Forwarded-Proto {scheme}
                #transparent
        }
        proxy /events localhost:8878 {
                websocket
        }
        log /var/log/caddy/tree_access.log
        errors /var/log/caddy/tree_error.log
}

This time a bit more informations as a kinda last attept :stuck_out_tongue:

To see if there is really nothing else broke i removed this three lines again:

Aaand again with your suggestion:
(yes, i gave up on hiding the domain name - makes no sense anyway)

Well - setting up taiga was not “that” big fun - at least on archlinux - because the deps are only documented for debian/-based ::smirk:
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… :laughing:
If there is really no solution i may really try to trick with nginx. :disappointed_relieved:

Update: turns out change-email/ link is finally working :stuck_out_tongue:
Well, at least one thing xD

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. :slight_smile:

1 Like

Nice work. Edited my post to include the if statement too. :thumbsup:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.