Skip to content
This repository has been archived by the owner on Jun 13, 2023. It is now read-only.

Error Domain=SRWebSocketErrorDomain Code=2132 "received bad response code from server 404" #33

Closed
yz opened this issue May 6, 2016 · 13 comments

Comments

@yz
Copy link

yz commented May 6, 2016

We are getting this error with live query. Anyone has any tips on what might caused it?

@richardjrossiii richardjrossiii self-assigned this May 6, 2016
@richardjrossiii
Copy link
Contributor

My best guess is that you don't have the proper URL for your LiveQuery server. Can you show us the URL you used?

@yz
Copy link
Author

yz commented May 7, 2016

sure, we are using nginx 1.8.1 distributing using distelli of the parse sample server with the live query on and with mount path as / and with 'npm ws' called before 'npm start'. Parse node server is running fine and accessible via dashboard. Any quick way to test if the web socket is working?

upstream parseNodeServer {
server 127.0.0.1:9000;
}

location /ot/ {
       proxy_pass http://parseNodeServer/;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection 'upgrade';
       proxy_set_header Host $host;
       proxy_cache_bypass $http_upgrade;
    }

@richardjrossiii
Copy link
Contributor

Everything there seems good...

Other than using the existing LiveQuery clients we have, not that I know of. What about the URL you configured the client with? Is it possible you're missing a trailing slash (that happens to be important for the default node implementation of LiveQuery)?

@yz
Copy link
Author

yz commented May 9, 2016

on the iOS client side
configuration.server = "https://api.myserver.com/ot"

tried it with the trailing slash
configuration.server = "https://api.myserver.com/ot/"
and getting the same error.

Since the live query piggy back the parser server URL, if the parse server URL is working, we assume the live query URL should be good.

@nlutsenko
Copy link
Contributor

@yz, since you are using https, could you try changing the ws:// scheme that we are using for Web Socket communication to wss, which is the SSL counterpart for ws (similar to http vs https).
The code for this lives here https://github.com/ParsePlatform/ParseLiveQuery-iOS-OSX/blob/master/Sources/ParseLiveQuery/Client.swift#L53

This wasn't yet released, but is available on the latest master.
You could also try just using the LiveQuery client from master via CocoaPods.
I hope this is what we are looking for, as with everything else here it looks to be that way.

@yz
Copy link
Author

yz commented May 9, 2016

@nlutsenko @richardjrossiii found the bug related to this issue, it was due to that the path component in the Client.swift is hardcoded. It should be appending since our server, i suspect others, are using a reverse proxy with a location route. So the current implementation will fail for any parser server with a location route.

Change the following line in the Client.swift fixed this 404 error.
components.path = "/LQ" // this is currently hardcoded.
Change to below will resolve the 404 issue. Let me know if a you want me to do a PR.
components.path = (components.path! as NSString).stringByAppendingPathComponent("/LQ")

That said, after this 404 issue is resolved, was able to run and connect to the Chat room example, however, couple of new issues, messages are not showing up in the Dashboard (due to schema?) but did get created in the database and updates via mlab admin/browser did not trigger the subscription.

That said, is there a working sample for iOS client app?

@nlutsenko
Copy link
Contributor

Yup, that would be it, we are discussing right now on the best way to resolve this that would allow setting the path. We are currently requiring for the path to be hardcoded into the URL according to the setup of Live Query Server here.

In regards to messages not showing up in the Dashboard - are you using Parse.com dashboard?
Or own self-hosted one? @drew-gross should be able to help you on the dashboard end.

Be aware that changes through mlab admin should not trigger the subscription, because the Live Query Server is no aware of them. Meaning that changes are triggered only if they come to the server itself and not directly to the database.

@drew-gross
Copy link

@yz the dashboard and SDKs use a batch endpoint that requires your mount path to be the same as the URL you provide when you initialize your Parse SDK. I highly recommend you avoid any URL rewriting in your reverse proxy.

@yz
Copy link
Author

yz commented May 10, 2016

@nlutsenko yes, using the Parse's dashboard before and it does not show the messages. Switched to use local dashboard does show the messages. However, after connecting to the Room, it does not print out the existing messages, and by modifying via local dashboard (which goes thru the server) still does not trigger the live query.

@yz
Copy link
Author

yz commented May 10, 2016

@drew-gross our server has few node apps, and we are using nginx and each one has its own location, we are not rewriting url, simply route the location to each node.js app and without any any mount path simply / This happen to be necessary for the server push notification to work as raised in one of the thread (Non root routes break Push Notifications #87)

richardjrossiii added a commit that referenced this issue May 10, 2016
This hasn't been necessary for a long time with LiveQuery, and should
allow this to operate properly behind a reverse proxy or other scenarios
where precise path matters.

Fixes #33.
richardjrossiii added a commit that referenced this issue May 10, 2016
This hasn't been necessary for a long time with LiveQuery, and should
allow this to operate properly behind a reverse proxy or other scenarios
where precise path matters.

Fixes #33.
@aliasad106
Copy link

I'm having issue while deploying ParseLiveQuery on AWS. It's working locally but when I deploy on AWS and try to test. I get this error.
Error: Error Domain=SRWebSocketErrorDomain Code=2132 "received bad response code from server 404" UserInfo={NSLocalizedDescription=received bad response code from

@john1jan
Copy link

john1jan commented Feb 5, 2020

we are also facing the same issue for WebSocket connection in ios swift app

@slatqh
Copy link

slatqh commented Sep 5, 2020

same issue here
chrome debugger keep logout every second this message:
Error occurred, shutting down websocket connection: Websocket exception Error Domain=RCTSRWebSocketErrorDomain Code=2132 "received bad response code from server 403" UserInfo={NSLocalizedDescription=received bad response code from server 403, HTTPResponseStatusCode=403}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants