I think this because I've seen the pcap traces. The server closed the connection before it received the 2nd request -- it can't possibly send a status code. See my timeline in a sibling comment.
The Keep-Alive header [1] is optional, but has parameters timeout, indicating the idle timeout, and max, indicating the number of allowed requests. Max is useful for pipelining, to avoid sending requests that won't be processed; timeout is very helpful for avoiding sending requests when the server is about to close the socket.
Regarding the first question, IMO the webserver should half-close the socket. So, the on the wire requests are rejected on TCP level, while the final response is being delivered. Of course, the client needs to deal with socket errors in addition to http status codes.
For the keep-alive header, you are right, I wasn't aware of it.
In my scenario at time N, the connection is idle -- both sides have received all data the other has sent, all requests have received a response.
If the server half-closes (through shutdown) and sends a FIN, simultaneously with the client sending a new request; that enables the server to read the request, but not respond to it, so I don't see how that is helpful?
The problem from the client side is it's sent a request, and seemingly in response the socket is closed. That could indicate the server crashed on the request, or the server closed the socket because it was idle. If you have a request that you know or suspect shouldn't be made more than once, you shouldn't retry it on a new connection. Assuming the tcp packets from the server, you can actually take a good guess at causality, because the ACK number and TCP Timestamp indicate if the server saw your last transmission, but that information isn't exposed through normal the normal socket API; you could maybe guess based on round trip time too, but it is nicer in http/2 (or other protocols), where there is an explicit close message.
I think it depends mainly on the stakeholders. If we're talking about physical machines, I suggest location/hardware based naming. For virtual machines, I'd choose function/role based naming. Though, this depends on type and size of engineering staff that needs to work with it. For end users, I'd add service based names, possibly as cnames. And I'd plan to change the naming scheme as the requirements change.
Has anyone a naming scheme that lasted more than ten years?
I've left HN some time ago, when I came back here today, I've seen three PHP stories on the front page. I'd say: yes, it changes. But I must credit one PHP story was on Pharen, "A lispy language that compiles to PHP".
I think of something like a comment or an abstract; security is not an issue here because input validation and escaping is done elsewhere.
Basically, I think of a string like "ham, egg." which should result in "ham" and "egg", and "Ветчина, яйцо." should also result in "Ветчина" and "яйцо".
The challenge is that you cannot whitelist all possible characters as there are (imho) too many charsets.
Well barring the practice of specifying meaningful characters, the only thing I can come up with is to have your program use statistics to take it's best guess at what 'special' characters are. Let's say 95% of the characters are between 65 and 90, and every now and then there's a 44-32 pair. Then your program could be pretty sure that 44-32 is a delimiter, and that 65 and 90 are the ranges of characters used in keywords. (The above examples are ASCII).
However, that does nothing to eliminate words like 'in' and 'of' in a query, which you may want to do. It isn't very practical at all, I think, and you probably want to look at more practical ways to list possible delimiters, etc... Although the above could help you determine what charset you're using.
