Error I receive from Safari: Connection lost

Connection to what was lost?

Error I receive from Safari: Connection lost

Connection to what was lost?

Good question - after doing some other tests, it looks like that when Safari receives a 200 OK from the service worker, the page loaded properly.

If, instead, it gives a 30x Safari closes the connection, or, to say it better, the service worker somehow does something weird and throws an error.

Weird that on Chrome this isn't happening.

This makes my app not working since after the login, the user is 302'd to another page (the app main page).

I'm not sure why this is happening since it works on my local

Seems like something more to do with your browser than Railway then?

Try returning a full url in the location header instead of a relative path.

Try disabling the edge proxy for your service. I had a similar issue and the culprit was actually railway's proxy. It was somehow modifying the request in a way that Safari was rejecting.

Good call, if this works on the legacy proxy I can escalate this.

I had the exact same issues. Removing the new Edge-Proxy solved it!

Can you please try disabling the edge proxy as well?

Can you please try disabling the edge proxy as well?

I've disabled the proxy and it fixed the issue.

Thanks everyone for the support!

Can you please try disabling the edge proxy as well?

Hi, I'm having this same problem with my django application, I spent the whole week trying to understand this error, and from what I'm seeing it's the railway's edge proxy that is causing this error.

But when I try to disable the function it shows the following message:

Failed to update edge entry point

One of your domains is configured with target ports which requires the new proxy. Delete the domain before trying to disable the proxy.

I've already recreated the domain several times, but it's not working.

Do I have to disable this function in any specific configuration?

Remove domain, disable proxy, add domain back.

Is anyone able to share some information on how I could try to reproduce this to fix in the proxy ? I understand that some endpoints are returning a 30x and this is what causes Safari to close the connection.

We will not be able to look into this until we have reproduction steps

There is another thread that reported this issue, they shared a url that sends a redirect that results in this error - https://help.railway.app/questions/mobile-errors-on-i-os-with-302-redirects-e75dfb7a

Is anyone able to share some information on how I could try to reproduce this to fix in the proxy ? I understand that some endpoints are returning a 30x and this is what causes Safari to close the connection.

I was having this issue reliably with a user initiated oauth2 flow.

User requests and endpoint on my app which redirects them to a 3rd party authorize endpoint which contains a callback to my app in the query params.

The initial redirect works fine, but after authorizing my app in the 3rd party app (Spotify in this case), the subsequent redirect to my app would fail.

This behavior was only replicable in Safari. Both on mobile and desktop.

Remove domain, disable proxy, add domain back.

As soon as I remove domains and try to disable edge proxy I get an error:

Failed to update edge entrypoint

We were unable to update your edge entrypoint. Please contact support if this error persists.

My project uses gunicorn (port 8080). I have tested on Safari (redirecting doesn't work) and Chrome (everything works).

Hey iolmao, I have tried to make a reproducible example but I was unable to as the code I wrote to send a 302 redirect worked without issue on a webkit based browser when deployed to Railway with the edge proxy enabled, but when you first sent your link I was able to confirm the error on the same webkit based browser.

So would you mind switching back on the edge-proxy so I can test again?

Hey iolmao, I have tried to make a reproducible example but I was unable to as the code I wrote to send a 302 redirect worked without issue on a webkit based browser when deployed to Railway with the edge proxy enabled, but when you first sent your link I was able to confirm the error on the same webkit based browser.

So would you mind switching back on the edge-proxy so I can test again?

Done, and indeed the app isn't working anymore on Safari.

Honestly, I'm not 100% sure is due to a 302: this is only my assumption as the view.py in Django that checks Username and Password throws a 302 if the login is successful and redirects to another page. While the login page itself, throws a 200 OK and it looks good.

It could be that there are other factors which I couldn't find.

Let me know how I can help.

Cheers!

I seem to be missing the link to where I can test this?

I seem to be missing the link to where I can test this?

Apologies, here you go -> https://gym-buddy.up.railway.app/
https://gym-buddy.up.railway.app/login/ -> this should work with Safari, all the rest should give a "not connected" error, probably coming from the serviceworker.js

index redirects to login if you you're not logged in.

Are there some test credentials I should use?

I'm also noticing you are running in debug mode, never a good idea to do that in production, try disabling debug mode.

I'm also noticing you are running in debug mode, never a good idea to do that in production, try disabling debug mode.

Yeah I know - it's not a public product, it's just a personal hobby app for me to go to the gym :)

I'm still learning how to deploy the whole thing properly with Django.

You can just create a random user, go ahead.

Please try disabling debug mode.

Please try disabling debug mode.

Done, deploy is underway.

Please try disabling debug mode.

Sorry to come back only now, had to fix some debug = false issues.

Now that I've fixed everything and debug = false is working properly, the app is working on safari too with the proxy enabled.

IMHO the behavior is still weird because, at this point, it was weird it was working on Chrome.

Debug = False didn't fix anything, I was able to put together a minimal reproducible example and the team fixed the issue, all should be good now!