livio / liviohttpserver

A small, lightweight, embeddable HTTP server for Mac OS X or iOS applications

LivioHTTPServer

This project was forked from https://github.com/robbiehanson/CocoaHTTPServer, and retains the BSD 2-clause license. The code has been wrapped into a framework, and is Carthage ready.

Any questions about the code can probably be answered on the wiki for the original project.

---

LivioHTTPServer is a small, lightweight, embeddable HTTP server for Mac OS X or iOS applications.

Sometimes developers need an embedded HTTP server in their app. Perhaps it's a server application with remote monitoring. Or perhaps it's a desktop application using HTTP for the communication backend. Or perhaps it's an iOS app providing over-the-air access to documents. Whatever your reason, LivioHTTPServer can get the job done. It provides:

• Built in support for bonjour broadcasting
• IPv4 and IPv6 support
• Asynchronous networking using GCD and standard sockets
• Password protection support
• SSL/TLS encryption support
• Extremely FAST and memory efficient
• Extremely scalable (built entirely upon GCD)
• Heavily commented code
• Very easily extensible
• WebDAV is supported too!

Getting Started

If you’re using Carthage, simply add LivioHTTPServer to your Cartfile:

github "livio/LivioHTTPServer"

Make sure to add CocoaAsyncSocket.framework to "Linked Frameworks and Libraries" and "copy-frameworks" Build Phases. More Information on Carthage

To manually add LivioHTTPServer to your application:

1. Add the LivioHTTPServer repository as a submodule of your application's repository.
2. Run git submodule sync --quiet && git submodule update --init from within the LivioHTTPServer folder.
3. Drag and drop LivioHTTPServer.xcodeproj, Carthage/Checkouts/CocoaAsyncSocket/CocoaAsyncSocket.xcodeproj into the top-level of your application's project file or workspace.
4. On the "Build Phases" tab of your application target, add LivioHTTPServer.framework, and CocoaAsyncSocket.framework to the "Link Binary With Libraries" phase.
5. Add $(OBJROOT)/UninstalledProducts/include and $(inherited) to the "Header Search Paths" build setting (this is only necessary for archive builds, but it has no negative effect otherwise).
6. For iOS targets, add -ObjC to the "Other Linker Flags" build setting.

liviohttpserver's Issues

Running as CLI program?

Hi, not so much an issue, as a question... I've been using LivioHTTPServer in a Mac app that I've written and it works perfectly.

I'm now looking at adding the ability to run from the command line. In my main.m. When I call start on my server, it looks like everything starts (my delegate methods get called OK). I then add call [[NSRunLoop currentRunLoop] run] to keep main.m from falling out.

However, when I send an incoming request from a browser, I just get connection refused. I've tried launching using dispatch_async too, but that doesn't seem to help. I'm still digging, but thought I'd check to see if you have any thoughts/suggestions.

Thanks.

merge back into coccopod

why not merge it back as an newer version of coccopod ?

Deadlock when subclassing LHSServer to provide different config

I'm embedding LivioHTTPServer in a Swift app, and I've found a totally repeatable deadlock if you subclass LHSServer and override the config method. If you look at the default implementation of -[LHSServer config], it does the following:

return [[LHSConnectionConfig alloc] initWithServer:self documentRoot:documentRoot queue:connectionQueue];

In my custom LHSServer subclass, I can repeatedly create a deadlock by using the following Swift code:

func config() -> LHSConnectionConfig {
    return LHSConnectionConfig(server:self, documentRoot:self.documentRoot())
}

Pretty similar, no? The deadlock comes because the default implementation directly references the documentRoot instance variable, whereas the Swift code has to go through the -[LHSServer documentRoot] getter because the documentRoot instance variable isn't visible to Swift.

In the -[LHSServer documentRoot] getter, it performs a call to dispatch_sync(serverQueue). The problem is that earlier in the call stack -[STCPSocket doAccept:] (line 928) has previously called dispatch_async(delegateQueue) where delegateQueue is the same serverQueue object that the documentRoot getter is blocking against (see line 48 in -[LHSServer init]).

I haven't specifically tried it, but I am certain that the problem could also reliably be reproduced in Objective-C just by using [self documentRoot] instead of referencing the instance variable directly.

A few things I've tried are:

• Using (self.valueForKey("documentRoot") as! String). Doesn't work because it still calls the getter
• Calling super.config() and asking that temporary LHSConnectionConfig for its documentRoot. Doesn't compile because -[LHSServer config] is a not declared in the public header.
• Stop calling documentRoot. Fortunately, for me, this is actually OK as I am not relying on the built-in document root, so I can just pass a hard-coded empty string.

Dunno if there is going to be much that you can do about it, but I thought I'd capture the problem/possible solution for others to learn from.