Basic unsecured server not working about telegraph HOT 17 CLOSED

Interesting, it seems to be allowed on the actual device but not on the Simulator. See this StackOverflow post. I'm not really sure, I'd have to do some tests with this.

The unsecure server is working for me on iOS, without any problems.

@SmileAppDev are you retaining the Server instance? In TelegraphDemo I'm assigning the Server instance to a local variable so that it doesn't get deallocated then the setupServer function goes out of scope. If the Server instance gets deallocated, it will automatically stop and close the sockets.

If that isn't the problem, could you send me your example? I'd be happy to have a look, maybe I can find the problem.

from telegraph.

Did you make sure to access it on a correct IP (and port) and through HTTP not HTTPS? Also what does does not work mean? Does the app break or is it just that the server is not listening without any apparent error?

from telegraph.

I tried to connect to it using localhost:9000. By "does not work" I mean the code runs but can't access the server from the browser. There are no errors in the console.

When running the example code I get this:

But when I run the basic server I get this:

from telegraph.

You are using HTTPS in your second picture. You said you are configuring unsecure server - as your example code suggests as well. Does it work with http://?

from telegraph.

No, I tried that as well, I just didn't catch it for the picture.

http:// gets the same thing.

from telegraph.

I see. I don't have experience with using localhost, what I did was include the embedded (unsecured) server in an app and then connect to the phone's local network IP from a browser on a laptop (both the Mac I deployed the app from and a different one). What steps are you doing here to be able to use localhost? I am asking so I can try and reproduce this myself to try to help further if possible.

from telegraph.

Oh I just realized you are probably using a macOS app instead of an iOS app right? So the apps and the browser are in the same host thus localhost works in that scenario. I will try to reproduce that.

from telegraph.

Ya I am, I was just going to test if it works on IOS.

from telegraph.

It didn't work on IOS either.

from telegraph.

@SmileAppDev I am able to reproduce this issue. Can't assist you further sadly, but hopefully @Zyphrax will be. Interestingly, port 80 works for me on iOS no problem, but on macOS it throws "bad instruction"

from telegraph.

@SmileAppDev Ah, that is interesting. Let me upload an example for you to check out and try, I got this working on iOS no problem. Will get back to you within 3 hours.

from telegraph.

Ok, Thanks for the help!

from telegraph.

Port 80 and 443 are in the range of the protected port numbers. Unfortunately you are very likely to have issues when you use those port numbers. They require administrative privileges, which should be possible on macOS but not on the other platforms. See: why can't I use port 80 and 443.

A few minutes ago I've tested the unsecured server by:

• commenting out lines 23 and 24 in TelegraphDemo.swift, to disable the demo routine, they will all fail because they assume https.
• changed line 43 in that file to: server = Server()

Then I start up the macOS app and a fresh Chrome window and visit http://localhost:9000/status. That seems to work:

The root test site works as well:

Chrome is really eager to change your url to https if you've visited the site with http before. I'll try out the iOS version in a few minutes.

from telegraph.

@SmileAppDev Sorry I did not have time to get back to you, hopefully Yvo's suggestion to "downgrade" the secure demo will work for you
@Zyphrax I was able to use port 80 on iOS without any extra permissions or privileges - should I expect problems when going to the store with the app as opposed to in development (while deploying from the Mac to developer iPhone)?

from telegraph.

Thank you @Zyphrax the server was getting deallocated.

from telegraph.

@SmileAppDev Ah yes, that's an easy mistake to make. I'm glad this isn't a bug :)
Thanks for letting me know.

from telegraph.

Just a nod to @yvbeek for the "deallocation" hint. I'm also working on an app that serves out of localhost on *OS and ended up starting it in the main ContentView of the SwiftUI app. Likely saved me hours or days of frustration.

from telegraph.