1
votes

I am writing a multi-platform application that is a sort of 'proxy', designed to field HTTP requests and pass some of them to a remote server and respond to others directly. So it acts as both an HTTP client and an HTTP server.

I have been using the Indy 10 components in both Delphi and Lazarus, and they work well on desktop platforms. I have ported the project successfully to Windows, Linux, and MacOS using Lazarus. Now I am attempting to do the same to iOS, using Delphi XE4. I am currently running the project in the iOS Simulator on a Mac running OSX 10.8.2; later I will be targeting an iPad device.

But I'm finding that I can't get the TIdHTTPServer component to create a connection to an incoming request on iOS. I bind the server to an IP address and port and activate it; this starts the listener thread. But when I try to send a GET request to the server it raises the exception EIdIPVersionUnsupported, with the message "The requested IPVersion / Address family is not supported." This error happens whether I try to route the GET request from within the application itself, or externally from a browser running on another machine.

I normally bind the HTTP Server to the localhost IP address, as the proxy is intended to run as a background process fielding requests from the browser running in the foreground. For the external browser test, I bound it instead to the Mac's own IP address.

1

1 Answers

3
votes

The majority of Indy components, including TIdHTTPServer, work exactly the same way in iOS as they do on other platforms. The only thing that changed in Indy to support iOS was implementing the low-level socket API function calls (via the TIdStackVCLPosix class), and updating Indy's internal coding to support the new Embarcadero mobile compilers (ARC, etc).

TIdHTTPServer should work on iOS, as long as it has permissions to open a TCP/IP listening socket. An EIdIPVersionUnsupported exception means that a low-level socket API call was attempted using an IP version that TIdStackVCLPosix does not support for that particular API call. All of the TIdStackVCLPosix methods support IPv4 and IPv6. So, without seeing the actual stack trace leading up to the exception, I can only guess that maybe Posix's accept() function is reporting that the connected client is using a socket address type other than IPv4 or IPv6.

With that said, I did just fix a minor bug in TIdStackVCLPosix.Accept() where it was not initializing the size of its address storage before calling POSIX's accept() function, so that may or may not be a contributing factor. Grab the latest Indy 10 SVN release (which has other bug fixes that did not make it into the XE4 release) and try again.