I know that, the http clients sends 0x10 0x13 bytes to inform the http server that the request data has finished.
But how the server informs the http clients that the response data has finished? (it sends -1 i.e. <EOF> correct)?
No. HTTP Clients do not send CRLF to the server to indicate that the request is complete, and servers do not send a particular byte sequence to the client to indicate completion. You should read this document: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 to understand how clients and servers are able to determine when a request or response is complete. The short summary is that the Content-Length header, Chunked Transfer-encoding terminator, or TCP/IP connection closure are all used as signals.
Related
I have a problem where the HTTP client sends a valid settings change request using digest authentication, which is processed by the server, but the request results in a delay of ~1 second in sending the HTTP ACK.
Due to the delay, the client resends the request. Because it's a resend, the nonce count is the same as the original. The server expects the nonce count to increment with each request, and so flags the resent request as a replay attack, and asks the client to reauthenticate.
What is the correct solution to this problem? I don't want to send the ACK before processing the request, because I need to know that the request succeeded before I send a 200 OK message.
I am testing my proxy server and have got a problem with connection close header from the client. If I try to response from the server with identity transfer-encoding it's limited with 390 bytes. After reading wireshark I decided that the my problem came from the limits of the tcp.reassembled.length and 390 payload is matches for the 512 of tcp.reassembled.length. Chunked responses doesn't work at all.
As I understand, if the client sends connection-close header the server should answer with only one packet and the sending payload is an undefined behaviour?
"As I understand, if the client sends connection-close header the server should answer with only one packet and the sending payload is an undefined behaviour?"
Not, it means that the server should send the full response and then close the connection.
I have two questions on HTTP Connection close:
If a client sends a HTTP request with Connection: close to HTTP Server, Is it the HTTP Server or client responsibility to send TCP FIN after response is received by client?
If a client sends a bad formatted HTTP request, and server sends a 400 BAD REQUEST, is it best practice to close the connection by server (even though the HTTP request has connection: keep-alive) or is it good practice to keep the connection still active?
Thanks in advance for answering my queries?
When the server receives a 400 Bad Request, it is going to send the response with the keep-alive header because if the client feels like sending another request, then they can use a pre-existing connection (this connection is shut down within a certain amount of time, it has an expiration date). The Keep-Alive Header is more about not saturating the network with TCP connection demands. You basically say "I am going to talk to you, for 2 minutes, whatever you send me, I'll answer you though this connection"
The server is only an object that receives commands from an user. You ask him, he does or not. The TCP FIN is something you send to the server to shut down the connection, but you choose when you don't want to communicate with him anymore. The client transmits the first FIN, and receives an ACK to ensure that the server got it. Then the server launches its own FIN, and waits for the ACK. If everything is okay, you and your server are no longer friends.
HTTP Protocol: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#header.expect
A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message
If the server wish to close the connection it will include "Connection: close" in his response. But how can it tell the client it wish to continue reading and discarding the body ? I don't know any header to do that.
And if it receive the body and discard it, this doesnt mean that "100-Continue" is useless ? That's the whole point of "100-Continue", not sending the body if it will be rejected anyway.
When the server sends its final reply, it has finished processing the request. If the server sends that reply while the client is still sending its data, the client should stop sending, and then the presense of an HTTP keep-alive (an explicit Connection: keep-alive header in an HTTP 1.0 reply, or a missing Connection: close header in an HTTP 1.1 reply) is the server's indication that it will be discarding any remaining data that is sent, since it needs to clear the socket of pending data before it can receive a new request on the same connection.
The 100-Continue is not useless. Think of what happens when the server sends 100 to let the client start sending, then later errors and decides to stop receiving and send a final reply reporting the error. The server did not know at the start of the request that it was going to error.
Suppose I initiate a TCP connection for HTTP request and response. After the completion of three way handshaking process, I now send a request to the server for a HTTP packet with SYN flag set. The server responses to my request with ACK flag. Upon completion of the response, it will send me a FIN flag. Now how can I determine the size of the packet that the server send me during the request and response? Is there any process to do so?
Suppose I initiate a TCP connection for HTTP request and response. After the completion of three way handshaking process, I now send a request to the server for a HTTP packet with SYN flag set.
No you don't. The SYN was in the first packet sent in the three-way handshake. That's done. At best you will be piggy-backing the HTTP request on the final ACK packet of the connect handshake.
The server responses to my request with ACK flag.
No, the server responds to your HTTP request with an HTTP response. The ACK is irrelevant at the HTTP level.
Upon completion of the response, it will send me a FIN flag.
No it won't, unless you're speaking HTTP 1.0 or you have set the Connection: close header. Otherwise it will keep the connection open for HTTP keepalive.
Now how can I determine the size of the packet that the server send me during the request and response? Is there any process to do so?
The server didn't send you anything during the request. The size of the response body is given by the Content-length header or the sum of the chunked-encoding section sizes if that's used. You need to read the HTTP 1.1 RFC about this, it's non-trivial.
You also need to stop confusing HTTP with TCP. HTTP is an application protocol layered on top.