"503 Service Unavailable" for docs.codeberg.org #640

austinhuang commented 2022年07月01日 20:28:40 +02:00

Title.

Please let me know if I should've reported to Codeberg/documentation instead

Title. Please let me know if I should've reported to Codeberg/documentation instead

fnetX commented 2022年07月01日 20:48:51 +02:00

works for me 🤔

works for me 🤔

austinhuang commented 2022年07月01日 20:49:37 +02:00

I guess it does now but it definitely wasn't the case when I created this issue

I guess it does now but it definitely wasn't the case when I created this issue

fnetX commented 2022年07月01日 20:50:10 +02:00

We'll keep an eye on it. Probably related to the Pages Server.

We'll keep an eye on it. Probably related to the Pages Server.

ailin-nemui commented 2022年07月01日 22:31:19 +02:00

fyi I have the same issue

fyi I have the same issue

fnetX commented 2022年07月01日 22:50:48 +02:00

Does it persist? Our monitoring does check the page regularly, and we didn't notice any issues yet ... would be helpful to learn e.g. how long the issue persists when you refresh the pages. Just single shot (working upon reload), persisting a few seconds etc

We appreciate any further information. Thank you for the report, both!

Does it persist? Our monitoring does check the page regularly, and we didn't notice any issues yet ... would be helpful to learn e.g. how long the issue persists when you refresh the pages. Just single shot (working upon reload), persisting a few seconds etc We appreciate any further information. Thank you for the report, both!

ailin-nemui commented 2022年07月01日 22:51:48 +02:00

for me it persisted for ~1 minute (tried to refresh several times), then I got bored, currently it works again, but I don't know how long it was unavailable.

additional info: it also broke the styling on blog.codeberg.org

for me it persisted for ~1 minute (tried to refresh several times), then I got bored, currently it works again, but I don't know how long it was unavailable. additional info: it also broke the styling on blog.codeberg.org

austinhuang commented 2022年07月01日 22:57:54 +02:00

For me it didn't work for around 5 minutes

For me it didn't work for around 5 minutes

Ghost commented 2022年07月03日 01:12:28 +02:00

I'm getting this issue now too.

I'm getting this issue now too.

Gusted commented 2022年07月03日 01:20:04 +02:00

What is getting rendered on the screen(try to create a screenshot)? We're having troubles of pin pointing the issue, does it say anything else besides 503?

What is getting rendered on the screen(try to create a screenshot)? We're having troubles of pin pointing the issue, does it say anything else besides 503?

Ghost commented 2022年07月03日 01:23:30 +02:00

On docs.codeberg.org I'm getting:

image

On codeberg.pages:

image

On docs.codeberg.org I'm getting:  On codeberg.pages: 

Ghost commented 2022年07月03日 01:25:57 +02:00

Interestingly opening an Incognito/Private window and accessing the site seems to work fine. Disabling my extensions seems to not change anything.

Interestingly opening an Incognito/Private window and accessing the site seems to work fine. Disabling my extensions seems to not change anything.

Ghost commented 2022年07月03日 01:30:25 +02:00

Okay discovered something strange, blocking third-party cookies seems to fix it for some reason, whenever third-party cookies are allowed the website seems to break.

Edit: Unless you guys fixed it just now.

Okay discovered something strange, blocking third-party cookies seems to fix it for some reason, whenever third-party cookies are allowed the website seems to break. Edit: Unless you guys fixed it just now.

fnetX commented 2022年07月03日 02:02:50 +02:00

We assume it's a scaling issue and some random bug that happens to some users for some short period of time. Interestingly, our monitoring never yet had any issues loading one of our test ressources, and we can't correlate errors with failing requests (we'd probably need to have exact timestamps of the errors to see if we can find something in the logs).

We have tons of request aborts etc, it might be some proxy / network issue, but it might also just be someone who stopped loading the page. We can't know for sure, unless we can directly map an error to a log line.

We assume it's a scaling issue and some random bug that happens to some users for some short period of time. Interestingly, our monitoring never yet had any issues loading one of our test ressources, and we can't correlate errors with failing requests (we'd probably need to have exact timestamps of the errors to see if we can find something in the logs). We have tons of request aborts etc, it might be some proxy / network issue, but it might also just be someone who stopped loading the page. We can't know for sure, unless we can directly map an error to a log line.

Gusted commented 2022年07月03日 02:09:06 +02:00

@hanna Thank you for your screenshots and your findings about the incognite + cookies, that provides insightful information for us. We're still investigating and trying to pinpoint the error so it shouldn't be fixed (or some bitflip did the work for us).

@hanna Thank you for your screenshots and your findings about the incognite + cookies, that provides insightful information for us. We're still investigating and trying to pinpoint the error so it shouldn't be fixed (or some bitflip did the work for us).

Gusted commented 2022年07月03日 03:47:39 +02:00

I'd observed something interesting. I wasn't able to reproduce this issue whatsoever across multiple machines. But on Chromium I was able to hit the issue for a minute or two after installing uBlock origin, after trying to remove it and restarting I was able to access docs.codeberg.org normal and re-installing ublock origin didn't help(so it was likely not related?). I did save the cURL command of the network request to docs.codeberg.org to compare, which interestingly has a difference.

On 503 error:

curl 'https://docs.codeberg.org/' \
 -H 'authority: docs.codeberg.org' \
 -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
 -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
 -H 'cache-control: no-cache' \
 -H 'pragma: no-cache' \
 -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \
 -H 'sec-ch-ua-mobile: ?0' \
 -H 'sec-ch-ua-platform: "Linux"' \
 -H 'sec-fetch-dest: document' \
 -H 'sec-fetch-mode: navigate' \
 -H 'sec-fetch-site: none' \
 -H 'sec-fetch-user: ?1' \
 -H 'upgrade-insecure-requests: 1' \
 -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \
 --compressed

Normal:

curl 'https://docs.codeberg.org/' \
 -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
 -H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \
 -H 'Cache-Control: no-cache' \
 -H 'Connection: keep-alive' \
 -H 'Pragma: no-cache' \
 -H 'Sec-Fetch-Dest: document' \
 -H 'Sec-Fetch-Mode: navigate' \
 -H 'Sec-Fetch-Site: none' \
 -H 'Sec-Fetch-User: ?1' \
 -H 'Upgrade-Insecure-Requests: 1' \
 -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \
 -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \
 -H 'sec-ch-ua-mobile: ?0' \
 -H 'sec-ch-ua-platform: "Linux"' \
 --compressed

The most interesting thing here is authority header on the 503 error. According to the HTTP specification it was introduced in HTTP/2. However pages-server is currently only able to handle HTTP/1.1 requests(Due to the underlying http implementation not having HTTP/2 support).

So it seems like for some reason the browser is expecting that the server is able to handle a HTTP/2 requests. I'm not sure yet but this seems like a interesting bug to investigate. It could be related that codeberg.org itself is HTTP/2 capable(maybe the browser messes up and thinls all subdomains are also fine due to that).

@fnetX within the logs there is tls: client requested unsupported application protocols that each time has two requests(exactly the amount of request you send when you receive 503 error) which indicates that the client isn't offering HTTP/1.1. FastHTTP doesn't support HTTP/1.0 or HTTP/0.9 for what's worth.

I'm not sure if this is the issue, but there are some pointers here that indicate that the browser is somehow not sending a HTTP/1.1 request and that HAProxy is still (somehow) sending a 503 error due to pages-server not able to handle the response.

OT: We might want to explore going to use another http implementation. HTTP/3 is getting traction and we still here using HTTP/1.1 well Go's http package just supports HTTP/2 out-of-the-box. Unless fasthttp's performance has great benefits, it might be the cause of instability.

---

Btw, does anyone have this bug on Firefox? Only able to have this issue reproduce on Chromium once.

I'd observed something interesting. I wasn't able to reproduce this issue whatsoever across multiple machines. But on Chromium I was able to hit the issue for a minute or two after installing uBlock origin, after trying to remove it and restarting I was able to access docs.codeberg.org normal and re-installing ublock origin didn't help(so it was likely not related?). I did save the cURL command of the network request to docs.codeberg.org to compare, which interestingly has a difference. On 503 error: ``` curl 'https://docs.codeberg.org/' \ -H 'authority: docs.codeberg.org' \ -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \ -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \ -H 'cache-control: no-cache' \ -H 'pragma: no-cache' \ -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'sec-ch-ua-platform: "Linux"' \ -H 'sec-fetch-dest: document' \ -H 'sec-fetch-mode: navigate' \ -H 'sec-fetch-site: none' \ -H 'sec-fetch-user: ?1' \ -H 'upgrade-insecure-requests: 1' \ -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \ --compressed ``` Normal: ``` curl 'https://docs.codeberg.org/' \ -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \ -H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \ -H 'Cache-Control: no-cache' \ -H 'Connection: keep-alive' \ -H 'Pragma: no-cache' \ -H 'Sec-Fetch-Dest: document' \ -H 'Sec-Fetch-Mode: navigate' \ -H 'Sec-Fetch-Site: none' \ -H 'Sec-Fetch-User: ?1' \ -H 'Upgrade-Insecure-Requests: 1' \ -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \ -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'sec-ch-ua-platform: "Linux"' \ --compressed ``` The most interesting thing here is `authority` header on the 503 error. According to the HTTP specification it was introduced in HTTP/2. However pages-server is currently only able to handle HTTP/1.1 requests(Due to the underlying http implementation not having HTTP/2 support). So it seems like for some reason the browser is expecting that the server is able to handle a HTTP/2 requests. I'm not sure yet but this seems like a interesting bug to investigate. It could be related that codeberg.org itself is HTTP/2 capable(maybe the browser messes up and thinls all subdomains are also fine due to that). @fnetX within the logs there is `tls: client requested unsupported application protocols` that each time has two requests(exactly the amount of request you send when you receive 503 error) which indicates that the client isn't offering HTTP/1.1. FastHTTP doesn't support HTTP/1.0 or HTTP/0.9 for what's worth. I'm not sure if this is the issue, but there are some pointers here that indicate that the browser is somehow not sending a HTTP/1.1 request and that HAProxy is still (somehow) sending a 503 error due to pages-server not able to handle the response. OT: We might want to explore going to use another http implementation. HTTP/3 is getting traction and we still here using HTTP/1.1 well Go's http package just supports HTTP/2 out-of-the-box. Unless fasthttp's performance has great benefits, it might be the cause of instability. ---- Btw, does anyone have this bug on Firefox? Only able to have this issue reproduce on Chromium once.

Ghost commented 2022年07月03日 06:45:27 +02:00

Running cURL with the --http2 flag seems to work fine with the above 503 command:

 curl --http2 'https://docs.codeberg.org/' \
 -H 'authority: docs.codeberg.org' \
 -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
 -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
 -H 'cache-control: no-cache' \
 -H 'pragma: no-cache' \
 -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \
 -H 'sec-ch-ua-mobile: ?0' \
 -H 'sec-ch-ua-platform: "Linux"' \
 -H 'sec-fetch-dest: document' \
 -H 'sec-fetch-mode: navigate' \
 -H 'sec-fetch-site: none' \
 -H 'sec-fetch-user: ?1' \
 -H 'upgrade-insecure-requests: 1' \
 -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \
 --compressed

More interestingly, looking at cURL's documentation:

Since 7.47.0, the curl tool enables HTTP/2 by default for HTTPS connections.

On their documentation page for HTTP/2.

Running cURL with the `--http2` flag seems to work fine with the above 503 command: ``` curl --http2 'https://docs.codeberg.org/' \ -H 'authority: docs.codeberg.org' \ -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \ -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \ -H 'cache-control: no-cache' \ -H 'pragma: no-cache' \ -H 'sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'sec-ch-ua-platform: "Linux"' \ -H 'sec-fetch-dest: document' \ -H 'sec-fetch-mode: navigate' \ -H 'sec-fetch-site: none' \ -H 'sec-fetch-user: ?1' \ -H 'upgrade-insecure-requests: 1' \ -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \ --compressed ``` More interestingly, looking at cURL's documentation: > Since 7.47.0, the curl tool enables HTTP/2 by default for HTTPS connections. On their [documentation page](https://curl.se/docs/http2.html) for HTTP/2.

ailin-nemui commented 2022年07月03日 09:22:35 +02:00

it also happens with Firefox

it also happens with Firefox

Gusted commented 2022年07月03日 11:27:55 +02:00

@hanna cURL kind of lies here. It will always be able to fallback to the correct http spec. So even specifying http2 on the request will still end up making a HTTP/1.1 request. You can confirm this by appending the "--sI" flag.

@hanna cURL kind of lies here. It will always be able to fallback to the correct http spec. So even specifying http2 on the request will still end up making a HTTP/1.1 request. You can confirm this by appending the "--sI" flag.

fnetX commented 2022年07月03日 12:33:31 +02:00

Is the 503 served immediately, or does it load for a while?

Is the 503 served immediately, or does it load for a while?

Gusted commented 2022年07月03日 12:56:38 +02:00

Is the 503 served immediately, or does it load for a while?

Was able to reproduce it ~15 minutes ago. It loads just as a normal webpage, immediately.

> Is the 503 served immediately, or does it load for a while? Was able to reproduce it ~15 minutes ago. It loads just as a normal webpage, immediately.

Gusted commented 2022年07月03日 15:56:41 +02:00

Hi everyone,

We've deployed a possible fix for this isssue. Please try to visit https://docs.codeberg.org again and see if you're able to hit the 503 error.

Hi everyone, We've deployed a possible fix for this isssue. Please try to visit https://docs.codeberg.org again and see if you're able to hit the 503 error.

Gusted commented 2022年07月04日 21:57:46 +02:00

A user reported a 503 error. We will continue with investigating.

A user reported a 503 error. We will continue with investigating.

zander commented 2022年07月04日 23:42:45 +02:00

Both docs.codeberg.org and something.pages websites are currently hosted using the 'pages service' (part of gitea).

As all those sites per definition have a limited set of pages of only HEAD (not some branches or whatever), the question this raises is why not simply generate static html files that are written to disk and served by an off-the-shelf webserver (like nginx).

This is how github and gitlab pages work, and its a hell of a lot cheaper to do on the server side. Plus, you avoid errors like this at a basic level.

Both docs.codeberg.org and something.pages websites are currently hosted using the 'pages service' (part of gitea). As all those sites per definition have a limited set of pages of only HEAD (not some branches or whatever), the question this raises is why not simply generate static html files that are written to disk and served by an off-the-shelf webserver (like nginx). This is how github and gitlab pages work, and its a hell of a lot cheaper to do on the server side. Plus, you avoid errors like this at a basic level.

fnetX commented 2022年07月05日 01:02:41 +02:00

The pages service is written by Codeberg. But yes, together with Codeberg/pages-server#72 I also considered if we shouldn't just make sure that pages repos are directly checked out.

The issue: Some users host e.g. 8GB pages repos. We'd duplicate the required disk size if we store the files in Git and as plain files.

The pages service is written by Codeberg. But yes, together with https://codeberg.org/Codeberg/pages-server/issues/72 I also considered if we shouldn't just make sure that pages repos are directly checked out. The issue: Some users host e.g. 8GB pages repos. We'd duplicate the required disk size if we store the files in Git and as plain files.

zander commented 2022年07月05日 12:27:29 +02:00

Some users host e.g. 8GB pages repos.

Maybe companies or people that use significantly more space should host it themselves, or pay for it.

If you don't it will cause the codeberg infra to be abused and normal people's experience to be degrated.

A quick search on github limits gives this (older) answer;

https://stackoverflow.com/questions/28706454/github-pages-site-size-limits

Which basically states that at most levels (github pushes, pages, bandwidth) there are limits in place.

I honestly don't know if codeberg has limits today, but if it doesn't I'd argue that they should. To avoid inevitable abuse of public resources.

> Some users host e.g. 8GB pages repos. Maybe companies or people that use significantly more space should host it themselves, or pay for it. If you don't it will cause the codeberg infra to be abused and normal people's experience to be degrated. A quick search on github limits gives this (older) answer; https://stackoverflow.com/questions/28706454/github-pages-site-size-limits Which basically states that at most levels (github pushes, pages, bandwidth) there are limits in place. I honestly don't know if codeberg has limits today, but if it doesn't I'd argue that they should. To avoid inevitable abuse of public resources.

Ghost commented 2022年07月05日 20:08:56 +02:00

Some users host e.g. 8GB pages repos.

Maybe companies or people that use significantly more space should host it themselves, or pay for it.

If you don't it will cause the codeberg infra to be abused and normal people's experience to be degrated.

A quick search on github limits gives this (older) answer;

https://stackoverflow.com/questions/28706454/github-pages-site-size-limits

Which basically states that at most levels (github pushes, pages, bandwidth) there are limits in place.

I honestly don't know if codeberg has limits today, but if it doesn't I'd argue that they should. To avoid inevitable abuse of public resources.

Wouldn't that be limitations on Gitea since that's the software they use?

> > Some users host e.g. 8GB pages repos. > > Maybe companies or people that use significantly more space should host it themselves, or pay for it. > > If you don't it will cause the codeberg infra to be abused and normal people's experience to be degrated. > > A quick search on github limits gives this (older) answer; > > https://stackoverflow.com/questions/28706454/github-pages-site-size-limits > > Which basically states that at most levels (github pushes, pages, bandwidth) there are limits in place. > > I honestly don't know if codeberg has limits today, but if it doesn't I'd argue that they should. To avoid inevitable abuse of public resources. Wouldn't that be limitations on Gitea since that's the software they use?

Gusted commented 2022年07月05日 20:20:05 +02:00

Please move this discussion elsewhere, it has zero relevance to this issue.

Please move this discussion elsewhere, it has zero relevance to this issue.

XADE commented 2022年07月09日 15:47:54 +02:00

Codeberg-CI/feedback#44

similar issue, opened 2 months ago

will repeat here,
503 is returned when the user is logged in. For now docs can be opened in incognito mode

https://codeberg.org/Codeberg-CI/feedback/issues/44 similar issue, opened 2 months ago will repeat here, 503 is returned when the user is logged in. For now docs can be opened in incognito mode

Ghost commented 2022年07月13日 06:51:28 +02:00

I've been having 503's on https://docs.codeberg.org for quite a long time now, was having them at 18:00 EST (GMT-4) and still having the issue at 00:50 EST (GMT-4), mentioned the former on another issue, here. I recall timestamps being wanted so it could be looked more into at specific times, and around those times I seem to be having consistent 503s.

I've been having 503's on https://docs.codeberg.org for quite a long time now, was having them at 18:00 EST (GMT-4) and still having the issue at 00:50 EST (GMT-4), mentioned the former on another issue, [here](https://codeberg.org/Codeberg-CI/feedback/issues/44#issuecomment-552799). I recall timestamps being wanted so it could be looked more into at specific times, and around those times I seem to be having consistent 503s.

jwildeboer commented 2022年07月23日 22:15:38 +02:00

I can reliably reproduce this behaviour (with a M1 MacBook Air runnig Safari, OS and browser newest version, not beta) when I am on ci.codeberg.org and click on the docs link at the top of the page. ALways a 503. Restarting Safari and opening docs.codeberg.org directly fixes the issue. I haven't tried with Chrome or firefox.

I can reliably reproduce this behaviour (with a M1 MacBook Air runnig Safari, OS and browser newest version, not beta) when I am on ci.codeberg.org and click on the docs link at the top of the page. ALways a 503. Restarting Safari and opening docs.codeberg.org directly fixes the issue. I haven't tried with Chrome or firefox.

fnetX commented 2022年07月24日 02:11:21 +02:00

@jwildeboer Wow, nice spot – than you! I never managed to reproduce the 503 issue before, or maybe once. But this works for me, too. You don't even have to click that link, it's enough to visit the page directly before (does the browser still send a referer? Firefox here).
For me, the issue disappears after about one minute, maybe more or less.

I also forwarded the info in the Codeberg Infrastructure chat, hopefully someone who's more familiar with the Pages Server code can make use out of it.

@jwildeboer Wow, nice spot – than you! I never managed to reproduce the 503 issue before, or maybe once. But this works for me, too. You don't even have to click that link, it's enough to visit the page directly before (does the browser still send a referer? Firefox here). For me, the issue disappears after about one minute, maybe more or less. I also forwarded the info in the Codeberg Infrastructure chat, hopefully someone who's more familiar with the Pages Server code can make use out of it.

6543 commented 2022年07月24日 11:04:48 +02:00

Working on replacing http implementation ... then we can do a direct comparsion

Working on replacing http implementation ... then we can do a direct comparsion

jwildeboer commented 2022年07月24日 14:36:16 +02:00

When this happens to me (the 503 error), what typically comes next (after a few reloads) is that normal codeberg (gitea) pages become extremely slow to load, making it impossible to work. That's why my first supsicion was some sort of rate limiting on the codeberg side that tries to prevent too much traffic acting up.

When this happens to me (the 503 error), what typically comes next (after a few reloads) is that normal codeberg (gitea) pages become extremely slow to load, making it impossible to work. That's why my first supsicion was some sort of rate limiting on the codeberg side that tries to prevent too much traffic acting up.

jwildeboer commented 2022年07月24日 17:29:44 +02:00

Well YES, @momar - that seems to have fixed the issue of the 503 when coming from ci for sure! Thank you!

Well YES, @momar - that seems to have fixed the issue of the 503 when coming from ci for sure! Thank you!

momar commented 2022年07月24日 17:40:55 +02:00

Awesome - it's more of a workaround where HAProxy loops back to Pages again, but as long as it works for now that's great.

Awesome - it's more of a workaround where HAProxy loops back to Pages again, but as long as it works for now that's great.

jwildeboer commented 2022年07月25日 12:02:37 +02:00

The problem isn't solved, but I seem to get closer to the real problem. Right now, when I click on docs from ci.codeberg.org, I get a pages but the CSS is missing. See screenshot.

This morning I had the slow loading on normal codeberg pages again and yes, the GET for the css and js were stuck for at least 90 seconds after which I stopped the loading.

Something, something sometimes stops css and js from being sent.

The problem isn't solved, but I seem to get closer to the real problem. Right now, when I click on docs from ci.codeberg.org, I get a pages but the CSS is missing. See screenshot. This morning I had the slow loading on normal codeberg pages again and yes, the GET for the css and js were stuck for at least 90 seconds after which I stopped the loading. Something, something sometimes stops css and js from being sent.