Listening on the wrong port about kitura-net

[dfirsht]

Hey @da-na, the internal numbers do not have anything to do with what port the connection comes in on. Can you paste your routes here?

[chrisozenne]

@dfirsht: I had the same confusion as @da-na. My expectation was the same and I was surprised to see the accepted connection display a different port number for each request. I imagine if I was running a server on multiple ports that it would be more helpful to see the log telling me which of those ports was coming in to, i.e: 80 vs 443. What would be the advantage of the way that it currently is now?

[vadimeisenbergibm]

@da-na @chrisozenne I have fixed the log message to prevent the confusion - the printed port is the client port, it is not the a server port on which the application accepts incoming connections.

For more about local/remote ports and sockets, see this Stackoverflow answer

[chrisozenne]

Thank you!!

[da-na]

Thanks for fixing the log!

@dfirsht is there an easy way to print them out ? Like print(router.debugDescription) ? I'm asking as I didn't see it in the code, but maybe I'm missing sth. In case there's none .debugDescription it would be great if you could add it! Same thing for the request.debugDescription, as currently this Log.info("Request: \(request)") prints no valuable information.

I set them up this way:

func setupRoutes(router: Router, messages: MessagesArray) {
    Log.info("SETTING UP ROUTER")

    router.use("/*", middleware: BodyParser())
    router.all("/") {
        _, _, next in next()
    }
    // Get all the messages
    router.get("/") {
        request, response, next in

        Log.info("Request: \(request)")
        let json = JSON(MessagesArray.serialize(messages.getAll()))

        response.status(HttpStatusCode.OK).sendJson(json)

        next()
    }
    // Handle options
    router.options("/*") {
        request, response, next in

        response.setHeader("Access-Control-Allow-Headers", value: "accept, content-type")
        response.setHeader("Access-Control-Allow-Methods", value: "GET")

        response.status(HttpStatusCode.OK)

        Log.info("Options handling set")

        next()
    }
}

EDIT:
I've add Log.info to the serialize function, and in my code I get this log:
SERIALIZE: [["title": Blabla, "completed": 0, "id": 0, "text": n test, "date_created": 2016-03-15 14:08:23 +0000, "url": http://localhost:8090/messages/0, "originator": Me], ["title": Blabla, "completed": 0, "id": 1, "text": m test, "date_created": 2016-03-15 14:08:23 +0000, "url": http://localhost:8090/messages/1, "originator": Me]]

and then in the browser I get Json Unknown

for the original TodoList the log looks like this
SERIALIZE [["title": Reticulate splines, "completed": 0, "id": 0, "order": 0, "url": http://localhost:8090/todos/0], ["title": Herd llamas, "completed": 0, "id": 1, "order": 1, "url": http://localhost:8090/todos/1]]
and it produces

[
  {
    "title" : "Reticulate splines",
    "completed" : false,
    "id" : "0",
    "order" : 0,
    "url" : "http:\/\/localhost:8090\/todos\/0"
  },
  {
    "title" : "Herd llamas",
    "completed" : false,
    "id" : "1",
    "order" : 1,
    "url" : "http:\/\/localhost:8090\/todos\/1"
  }
]

Could NSDate be a problem? Or maybe the enum that I'm using for the originator? (It's an enum that inherits after String though)

[da-na]

Hi!
The solution is described here: SwiftyJSON/SwiftyJSON#421 (using the NSDate) and is not related to routing.

Thanks for all the help!

Would be awesome though if the *.debugDescription was added :)

[dfirsht]

Great! I'm going to close this then. Yeah I think a debug mode would help, that's something I would like to do in the future.