Closed Bug 1201592 Opened 8 years ago Closed 8 years ago
Local web server's socket connection becomes terminated when the app is backgrounded and the phone is locked
We currently configure GCDWebServer to not suspend when entering the background: https://github.com/mozilla/firefox-ios/blob/master/Client/Application/WebServer.swift#L22 The problem is that if we leave the socket open that accepts incoming connections in the background, it can be closed when application becomes suspended - leaving the web server not able to handle requests. The solution would be to turn on suspension on the web server to allow it to start/stop the server when the application becomes foregrounded/background. Note: This issue seems to be the root cause of https://bugzilla.mozilla.org/show_bug.cgi?id=1199584 and probable cause of https://bugzilla.mozilla.org/show_bug.cgi?id=1194501 so I'm marking it tracking+
Summary: Local web server's socket connection get terminated when the app is backgrounded and the phone is locked → Local web server's socket connection becomes terminated when the app is backgrounded and the phone is locked
:st3fan, I remember you mentioning you had issues with configuring GCDWebServer to suspend on background because of a changing port issue which is why we configured it to not suspend. Do you recall what those issues were?
Brian also knows more details about this specific one.
Flags: needinfo?(sarentz) → needinfo?(bnicholson)
This is what i know: * The web server picks a random port * When we leave the socket open, the port number never changes * When we close the socket on going to the background, the port changes The port change is problematic for localhost URLs that are *currently* in the backforwardlist or open in any tab. We cannot update those active pages or backforward lists, so they now point to URLs that do not exist anymore. I think this is the reason we did not close the socket. An alternative is that we use a fixed port. But then there is the danger that the port is already in use by another app.
So I feel pretty confident that we can use a fixed port and not worry about collisions with other apps. GCDWebServer uses BSD sockets under the hood which are essentially file descriptors. File descriptors are sandboxed on iOS to their either their own application or can be create inside an application group's shared container (for example, we can use sockets to communicate between extensions if we wanted) so since there is no way for other applications to access our file descriptors I think we're good. Some interesting related reading regarding IPC/XPC/Sockets on iOS/Mac OSX http://ddeville.me/2015/02/interprocess-communication-on-ios-with-berkeley-sockets/
Comment on attachment 8656758 [details] [review] https://github.com/mozilla/firefox-ios/pull/1033 So with this option, any requests to localhost will break while we're in the background (but not yet suspended). Theoretically, that means things like session restore or reader mode (which work by loading localhost URLs) could break if the user pushes the Home button at the wrong time. Have you tested this with session store, reader mode, etc. -- anything that might cause a delayed load to a localhost URL?
Ran some tests and it looks like session restore and reader mode work pretty well with the fixed port. I think what allows this to work is when GCDWebServer accepts a request, it starts processing it as a background task in case the application is backgrounded: https://github.com/swisspol/GCDWebServer/blob/master/GCDWebServer/Core/GCDWebServer.m#L248. This allows the app to continue finishing the request while the app is backgrounded.
Comment on attachment 8656757 [details] [review] https://github.com/mozilla/firefox-ios/pull/1032 OK, sounds like this is worth a try!
Attachment #8656757 - Flags: review?(bnicholson) → review+
Attachment #8656758 - Flags: review?(bnicholson) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.