7

RFC2616 part 4.4 specifies how the end of the message is determined in HTTP/1.1. Item 5 in that section specifies that the server may close the connection to indicate the response is finished.

It also goes on to say that delimiting the request like this is impossible. However, TCP allows the client to close its end and go on to receive a response. I've even tested it; it works.

Questions:

  • Why does a standard dated 1999 say this is impossible when it's actually possible? TCP was well established by then, and had supported half-close for a long time by then (possibly all the way since 1974?).

  • Is it a violation of the protocol for a client to half-close the connection to indicate end-of-request?

Please disregard whether this is a good idea: I am aware of how you sometimes can't quite tell whether the connection was closed on purpose or just broke, and how it makes a lot more sense to keep the connection open to reuse it later.

Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • Sounds like you're wandering off the map a bit here, but I'm really curious to know *how* you tested receipt of a message after closing the connection? I suspect that the connection wasn't closed - only that you'd sent a FIN packet. – symcbean Dec 28 '12 at 12:16
  • Perhaps because the spec is written so as to be independent of connection protocol and so they didn't want to rely too heavily on features that other protocols may not have – Frederick Cheung Dec 28 '12 at 12:16
  • @symcbean That's right, it wasn't closed. It was half-closed, which I think is another way to say that I sent a FIN packet but the other end remained open, i.e. just like you say. – Roman Starkov Dec 28 '12 at 14:06
  • The behaviour of TCP is not defined by the application, hence drawing conclusions about how TCP should behave from the HTTP RFCs is not a fruitful pursuit? Given the nature of a packet switched network, I'm not very surprised that the app can still receive and process data sent after emitting a FIN. But usually it's the client which closes the conection, most HTTP clients don't close a connection with a FIN, they use a RST, and in the case of the server sending a FIN packet and then sending subsequent data packets should not be possible (without MITM bit flipping). – symcbean Dec 28 '12 at 15:06
  • @symcbean I'm not sure what your point is. This question is not about how TCP should behave at all. Plus, half-closed connections are not some weird accident; it's a [properly supported feature](http://stackoverflow.com/questions/10787788/how-to-receive-data-after-initiating-tcp-connection-close). – Roman Starkov Dec 28 '12 at 22:08
  • 2
    @symcbean This is all completely irrelevant. There is no *reason* you should be 'surprised' that TCP has a half-close when it is defined in the RFC 793, and that in turn isn't a necessary consequence of packet switching networks per se. Your assertion about 'most HTTP clients' doesn't hold water. Your final sentence doesn't relate to anything that has been stated here either. In short your point eludes me as well. – user207421 Dec 29 '12 at 06:04
  • @romkyns: your analysis seems to be predicated on the client and server acting synchronously. TCP networks are not designed to work that way. – symcbean Dec 29 '12 at 23:23
  • @symcbean If that's what you mean by "send the entire request, signal end of request, wait for response" then yes. TCP networks emulate streams of bytes, where each direction's stream can be closed individually to signal end of stream. Can you point out a problem in *my thinking about TCP*, instead of a problem in *how I got to my conclusion*? – Roman Starkov Jan 03 '13 at 11:16

1 Answers1

3

It doesn't say a half-close is impossible. It just says 'closing the connection cannot be used to indicate the end of a request body', which is true. It simply doesn't consider the possibility of a half-close one way or the other. As it isn't mentioned in the RFC, I would say using it would be a violation of the protocol, and you should have no grounds for expecting servers to react accordingly: for example, a server would be entitled to just forget the request and close the connection on receiving the FIN.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Moreover, `nginx` works exactly that way. http://mailman.nginx.org/pipermail/nginx/2008-September/007388.html – darkk Mar 08 '16 at 13:23