How do I handle properly a client
Connection: close request field? As of now if I get this particular field I close the socket and wait for a following request from the client than reply again and start serving the data.
I don't know why my client/server communication is not working as the Apache Server I tested with.
Thanks for any clarifications...
CLIENT: HEAD /stream.mpeg HTTP/1.0 Host: 127.0.0.1 User-Agent: SuperPlayer Connection: Close SERVER: HTTP/1.0 200 OK Date: Wed, 1 Jun 2011 20:05:13 GMT Server: HTTP Server Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT Accept-Ranges: bytes Connection: Close Content-Type: audio/mpeg CLIENT: HEAD /stream.mpeg HTTP/1.0 Host: 127.0.0.1 User-Agent: SuperPlayer Connection: Close SERVER: HTTP/1.0 200 OK Date: Wed, 1 Jun 2011 20:05:13 GMT Server: HTTP Server Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT Accept-Ranges: bytes Connection: Close Content-Type: audio/mpeg 231489172304981723409817234981234acvass123412323 21312hjdfaoi8w34yorhadl4hi8rali45mhalo3i,wmotw 345fqw354aoicu43yocq2i3hr
CLIENT: GET /test.mp3 HTTP/1.0 Host: 192.168.1.120 User-Agent: SuperPlayer Connection: Close SERVER: HTTP/1.1 200 OK Date: Wed, 01 Jun 2011 19:15:11 GMT Server: Apache/2.2.16 (Win32) Last-Modified: Thu, 29 Apr 2010 21:06:34 GMT ETag: "14000000047049-4f75c8-4856680636a80" Accept-Ranges: bytes Content-Length: 5207496 Connection: close Content-Type: audio/mpeg ...d.....<).0.. ..........<[email protected] ( .h.$.J...1...i....A. ......c....a.9..!g.N...A. ........ ....>......|.......8....a......|..|N.............'>[email protected] .e...r.iL..#..IH...pR|.
Yes closing the socket is the right action to take. If the client is using this header properly, they are closing the socket on their end once they receive your response.
What I'm noticing here is that your server is not returning a
Content-Length header. Even though the client is issuing a HEAD request, based on the W3C proposal (sec. 9.4):
The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.
The key here is to make sure you're telling the client the size of the response without actually sending the data.