Fixing Issues With Service Worker HTTP Requests and Cloudflare
Debugging like there is no tomorrow
Some weeks ago, we had been observing some Gateway Timeouts that were captured through our frontend error monitoring. It is a PWA powered by Angular. The weird thing is that we could not figure out why this happens. It also only occurred in production. We did notice that some users were running into this more often than others. File upload endpoints seemed to be affected the most. Here’s an example error (sometimes, we saw 0 status code instead of 504):
{
error: None,
message: Http failure response for https://my-api.com/upload: 504 Gateway Timeout,
name: HttpErrorResponse,
ok: False,
status: 504,
statusText: Gateway Timeout,
url: https://my-api.com/upload
}Debugging is a part of the job and it can be interesting. Personally, the most annoying thing is bugs that cannot be reproduced reliably: when you do not know whether your fix attempt actually works as intended.
I reached out to our cloud provider’s support but they failed to find any issues on their side. The backend logs did not show any Gateway Timeout exceptions hence this meant that our backend does not intentionally throw these errors.
After some time, I was confident that service workers were at least partially responsible. found a hint in the Angular documentation which mentions the possibility of 504 Gateway Timeout being thrown when using service workers. This sounded like a good start. Also, I found issues related to file uploads in progressive web apps.
Fix number one: no more service worker for you!
This interceptor is used to bypass the service worker when making HTTP requests as there are some cases where the service worker might run into issues. Since we are not using the service worker for caching HTTP requests in our application at this moment, we can safely bypass the service worker for those requests.
This fixed a majority of the occasional 504 Gateway Timeout errors that users have been encountering. In these cases, this explained why we were unable to run into this locally as we were not running the service worker in the normal development mode. Luckily, modern Angular versions do allow to also run the service worker in local development using ng serve without issues which we have now enabled: this should help to catch future issues related to service workers earlier in the development lifecycle.
Fix number two: relax, Cloudflare!
Another case we encountered: Cloudflare blocking the request. This was tough to debug and I only found out incidentally when using Postman to call the respective endpoint: the logs and the error response did not give away this information. While we were not using Cloudflare directly at the time, our cloud provider was using it under the hood.
My hunch was on the payload: we have entities with properties which store HTML data that our users can edit with a WYSIWYG editor. I could imagine that Cloudflare (e.g. the Web Application Firewall?) is being overprotective, thinking there is something malicious going on there (maybe due to the escaping). Cloudflare provides great services for hosting and securing web applications and it makes sense to safeguard yourself from the point of a cloud provider.
Changing the code affecting the HTML escaping seems to have done the trick for now.
Conclusion
Thanks for reading this post about how we overcame issues with service workers and Cloudflare blocking certain HTTP requests in our Angular application. Modern distributed applications are complicated but we are always learning more about technologies we sometimes take for granted. Let me know in the comments about your experiences.
