3 ms·
This is better, and the only way to really prevent the primary problem. Why would an API be on HTTP at all?
by davedx 2y ago
This is better, and the only way to really prevent the primary problem. Why would an API be on HTTP at all?
- Aachen 2y agoWhy is it better? I can't think of large differences. What comes to mind are two human factors that both speak against it: - Having an HTTP error page informs the developer they did something wrong and they can immediately know what to fix, instead of blindly wondering what the problem is or if your API is down/unreliable - That page, or a config comment, will also inform the sysadmin that gets hired after you retire comfortably that HTTP being disabled is intentional. Turning something off that is commonly on might be a time bomb waiting for someone who doesn't know this to turn it back on Edit: Just saw this reason, that's fair (by u/piperswe) https://news.ycombinator.com/item?id=40505545 https://news.ycombinator.com/item?id=40505545 > If the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down If that immediately errors out on the first try, though, what is the risk of the key being intercepted? The dev would never put that in production, so I'm not sure how the pros and cons stack up. I also loved this suggestion from u/zepton which resolves that concern: https://news.ycombinator.com/item?id=40505525 https://news.ycombinator.com/item?id=40505525 invalidate API keys submitted insecurely
- davedx 2y agoWhy spend effort on this at all? Just don't run anything on HTTP. Devs don't need hand holding. Should you run your API on `localhos` in case they typo the hostname? Why does everything have to be so complicated?