Fix a bug below, /swiftcode/swift-http/Package.swift:4:11: error: single-quoted string literal found, use '"' name: 'swift-http' ^~~~~~~~~~~~ "swift-http" swift-build: exit(1): ["/usr/bin/swiftc", "--driver-mode=swift", "-I", "/usr/lib/swift/pm", "-L", "/usr/lib/swift/pm", "-lPackageDescription", "/swiftcode/swift-http/Package.swift"]

According to the documentation, Swift packages should follow the SemanticVersioning convention. Currently, this package is not installable as a dependency as the tag is named v0.1-linux.

I recommend to implement SemanticVersioning so developers will be able to pull it in as a dependency.

Here is what I get on my MAC:

madhur@Madhurs-MacBook-Pro:~/swift-http (master)
$ swift build
<unknown>:0: error: no such file or directory: 'build'

*This updates the Dockerfile and README a bit more to fit the current state of the lib.

*Added a method for generating/sending a basic http header *Added a method for generating/sending a basic http response

Now one can add the repo as a dependency to their Package.swift file. Then import it into their code.

If there are any other properties/functions that you think need to be made public, let me know and I'll fix it.

I was experimenting with deploying this code to a Cloud Foundry instance and ran into a few issues related to the way the sockets were being handled. With these changes it seems to work great!

• Modify flags so that the system won't send SIGPIPE when the app writes to a socket that has been closed by the other end
• Use the shutdown call before close to try to get the network stack to send off all its data before tearing down the connection. According to this, just calling shutdown is not guaranteed to be enough, but it seems to be sufficient for this particular case.

Thanks for sharing this code!

Shrinks the swiftbox image from 1.22 GB to 849.3 MB.

The result of each Dockerfile line is saved to its own fs layer, so temporary files take up space in the image if they aren't removed in the same line they are created in. Also apt-get clean frees up a little space.

The HTTP server currently is calculating Content-Length as a naive character count, but the header is supposed to be the byte size of the response contents. In the case of "Hello World", the two are equivalent, but, if the response contained special characters, the Content-Length would be incorrect:

print("moose".characters.count) // 5
print("møøse".characters.count) // 5
print("møøse".utf8.count) // 7

For semantic reasons, and for people who are copying the source to serve their own custom responses, we should provide the correct byte length.

Signed-off-by: David Celis [email protected]

At least on Ubuntu with the latest Swift & package manager build, I would get the following error before this modification:

/home/mz2/Projects/swift-http/Package.swift:4:11: error: single-quoted string literal found, use '"'
    name: 'swift-http'
          ^~~~~~~~~~~~
          "swift-http"
swift-build: exit(1): ["/home/mz2/usr/bin/swiftc", "--driver-mode=swift", "-I", "/home/mz2/usr/lib/swift/pm", "-L", "/home/mz2/usr/lib/swift/pm", "-lPackageDescription", "/home/mz2/Projects/swift-http/Package.swift"]

What I liked the most about this (now very dated) server written on Obj-C was how easy it was to extend it.

I propose the same for swift-http, that we add a protocol or base class for request handlers that will then be registered with the main class.

Once a request comes in, the HTTPRequest class will take the request and turn it into an object so that you have easy access to things like the HTTP method, request headers, body, URL parameters etc.

We could then either have the main HTTP class loop through an array of registered handlers and let the first handler that returns true for canHandleRequest handle the request (aka producing a response) or the developer adds an if-statement to the main.swift to figure out which handler should handle the request. Both scenarios might want to either default to a handler that returns the file as plain text or 404.

This is a pseudo-sample of what I am imagine, I am already working on a basic FileRequestHandler that simply returns the contents of a file as well as tries to figure out the proper Content-Type header based on the file extension.

The simple handler protocol

public protocol RequestHandlerProtocol {
  static func canHandleRequest(inout request: HTTPRequest) -> Bool
  static func handleRequest(inout request: HTTPRequest, inout response: HTTPResponse)
}

An example handler

public class DefaultRequestHandler: RequestHandlerProtocol {

  public static func canHandleRequest(inout request: HTTPRequest) -> Bool {
    return true
  }

  public static func handleRequest(inout request: HTTPRequest, inout response: HTTPResponse) {
    response.statusCode = 404
    response.body = "404 Not Found"
    response.addHeader("Content-Type", value: "text/plain")
  }
}

Example of the request handling (in http.swift, start function)*

// ...
let request = HTTPRequest(bytes: bufferRcv)
if DefaultRequestHandler.canHandleRequest(&request) {
    DefaultRequestHandler.handleRequest(&request, response: &response)
}
response.write(clientSocket)
// ...