Hacker News Reader

Comment by duckyio | Hacker News Reader

It's fairly simple right now as we're on fly.io with machines in SJC and BOS. Being able to configure regions and having more clarity over the metrics is on the list

View on HN

If you aren't already, you might want to do a HEAD request to cut down down on bandwidth usage. It'd be kinda messed up, but someone could just send you a few dozen gb's worth of data.

You'd get quite a few false positives

HEAD requests are sometimes handled separately, why not just drop the connection after the header?

It depends on what you're measuring. If you just want the "ping", then send a SYN packet, wait for a SYN-ACK. You're done.

If you want to get HTTP status message, send a HEAD request. If a server handles it differently than a GET without a body, that's not your problem. As an application developer, you might do this on purpose as a health check.

Sure, but if you're testing uptime, only the GET request matters. HTTP statuses are just one mode of failure. Timeouts are a major issue HEAD requests might not trip, for instance.

I'm not saying my solution is without flaws, just saying actually detecting "status" automatically isn't trivial and HEAD requests only expose one facet if this.

I’m not sure what you are saying makes sense. A HEAD request is (according to the http spec) a GET without the body. It can timeout, send cookies, status, etc. If someone decides not to implement the http spec properly, how is that your problem?

I mean if you want to provide value it is your problem.

Regardless, just because HEAD requests CAN time out doesn't mean they WILL, even in good faith. GET requests will surface precisely the same behavior browsers do.

Reply on news.ycombinator.com