When the field Connection: Keep-Alive is set inside a HTTP request, the connection is not closed after the response is sent.
How does the client and the server knows that the data is over?
The only way I believe this works is by setting the field Content-Length at the HTTP request and the response.
Is there any other way?
Related
I want to send my response data to to client with "Transfer-Encoding:trunked".
But I do not find the way to do it with Golang.
Is there any example for this?
The net/http server does not allow the application to control the transfer encoding.
The net/http server automatically uses chunked encoding when the application does not set the Content-Length response header and the connection can be reused (http/1 client requested keep-alive or http/1.1 client did not request connection close).
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token.
Could somebody please give an example of a common scenario the above paragraph is referring to?
Does that have anything to do with Connection: close header?
A good example, in HTTP/1.1, is Upgrade, to indicate that a client wishes to move from HTTP/1.1 to another protocol:
GET http://www.example.com/hello.txt HTTP/1.1
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
If this were a proxy, the Upgrade header should not be passed to any upstream servers, as it only makes sense for this connection.
The Keep-Alive header could also appear here in HTTP/1.0 but is now obsolete with HTTP/1.1.
I'm writing a HTTP client which doesn't have any encoding algorithms built into it yet. Therefore, I was wondering if there is a value for Accept-Encoding header to indicate this? like: "none" for example, or "text/plain" or similar ?
You can just omit the Accept-Encoding header if you don't support compression:
http://www.httpwatch.com/httpgallery/compression/
However, this will not prevent some servers sending you chunked encoded responses:
http://www.httpwatch.com/httpgallery/chunked/
on persistent "keep-alive" HTTP connections. You can disable persistent connections by adding a "Connection: close" request header and the server will simply close the connection after all the content has been returned in the response message.
Background: I am trying to get ApacheBench working on my custom server. I tried issuing ab -n 1 -c 1 http://localhost:1337/index.html and I sniffing the connection (with wireshark) I see wayyy more than one request is sent.
Example Request:
GET /index.html HTTP/1.0
Host: localhost:1337
User-Agent: ApacheBench/2.3
Accept: */*
(repeats more times than I care to count)
I assumed as RFC 1945 says "Except for experimental applications, current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response." This works with ApacheBench when I request one page. However, if I up the number of requests to 10, I get "Connection reset by peer." This makes sense considering that I closed the connection.
I tried the same procedure with Google, however, and it works fine there for both cases. So, how am I supposed to know when to close the connection for HTTP 1.0?
In HTTP 0.9, the server always closes the connection after sending the response. The client must close its end of the connection after receiving the response.
In HTTP 1.0, the server always closes the connection after sending the response UNLESS the client sent a Connection: keep-alive request header and the server sent a Connection: keep-alive response header. If no such response header exists, the client must close its end of the connection after receiving the response.
In HTTP 1.1, the server does not close the connection after sending the response UNLESS the client sent a Connection: close request header, or the server sent a Connection: close response header. If such a response header exists, the client must close its end of the connection after receiving the response.
I read in some articles that if we do not set content-length header in http request,we get the http response in chunks.(Transfer-encoding:chunked which is choosen by server implicitly in such case).In my java code I did not set content-length header.Still I am getting content-length header in my response instead of chunked transfer.please help.
You probably mean "do not set content-length header in http response".
Anyway, a servlet engine is free not to use chunked encoding if it can determine the length of the reponse before sending it.