Tipi.serve callback invoked twice about tipi HOT 3 CLOSED

I couldn't reproduce your issue, but then again I'm on Linux. How are you making requests to your server script? Using curl or a browser? If you're using a browser you'll see two requests because the browser makes a second request to /favicon.ico.

Please try the following code:

require 'bundler/setup'
require 'tipi'

puts 'Serving on http://localhost:4411/'
spin do
  Tipi.serve('0.0.0.0', 4411, { reuse_addr: true }) do |req|
    req.uri
    req.respond("Hello world!\n")
  rescue Exception => e
    p e
  end
  p 'done...'
end.await

This will print the requested uri for each incoming request.

As for the server port leaking after the process terminates, I have also noticed that. Here's an explanation for what's apparently happening (from https://hea-www.harvard.edu/~fine/Tech/addrinuse.html):

In order for a network connection to close, both ends have to send FIN (final) packets, which indicate they will not send any additional data, and both ends must ACK (acknowledge) each other's FIN packets. The FIN packets are initiated by the application performing a close(), a shutdown(), or an exit(). The ACKs are handled by the kernel after the close() has completed. Because of this, it is possible for the process to complete before the kernel has released the associated network resource, and this port cannot be bound to another process until the kernel has decided that it is done.

The solution is to use the reuse_addr option when calling Tipi.serve, as shown in the above example.

from tipi.

Please note that the request / response API is still evolving, and has actually been extracted into a separate gem: https://rubygems.org/gems/qeweney. Documentation is lacking for the moment.

from tipi.

You're right, it was the favicon! Why did I not think of that 😬
Thank you for explaining the background of requiring reuse_addr. Awesome gem, you've made! 😄
I'll check out qeweney -- noticed you're building a Roda style routing. I love the Roda/Sequel stack.

from tipi.