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.
Related
Where may I find all possible values of all HTTP headers with explanations and maybe with examples? For now I want to know all possible values of Connection header.
I'm reading WebSockets Protocol documentation (https://www.rfc-editor.org/rfc/rfc6455) and there is a Client example request:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
There is a Connection: Upgrade header here. What does value Upgrade mean? I tried to serch in Wiki, Mozilla and RFC docs but they do not have this info.
The set of field values is open-ended (it depends on header field names, which is open-ended).
The definition of "connection" can be found here: http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#header.connection
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.
My client sets the following headers:
Transfer-Encoding: chunked
Connection: Keep-Alive
When I retrieve responses I receive a Transfer-Encoding: chunked header but no Connection: Keep-Alive header. For this reason I believe I may only be receiving a partial response in my client.
Now my question is:
Is it mandatory to set the Connection: Keep-Alive property in HTTP/1.1 ?
In short, no. In the absence of a Connection header for messages adhering to HTTP/1.1 the default is a persistent Keep-Alive connection. If a connection header is present both parties should act accordingly given that header's value.
As stated by RFC 2616 Section 8.1.2:
A significant difference between HTTP/1.1 and earlier versions of HTTP
is that persistent connections are the default behavior of any HTTP
connection. That is, unless otherwise indicated, the client SHOULD
assume that the server will maintain a persistent connection, even
after error responses from the server.
Of course, this doesn't prevent you from explicitly setting a Connection: close header if you wish to close the connection once the transfer completes.
Solved: pasting the bytes here made me realise that I was missing empty lines between chunks...
Does an HTTP/1.1 request need to specify a Connection: keep-alive header, or is it always keep-alive by default?
This guide made me think it would; that, when my http server gets a 1.1 request, it is keep-alive unless explicitly receiving a Connection: close header.
I ask since my the different client behaviour of ab and httperf is driving me mad enough to wonder my sanity on this one...
Here's what httperf --hog --port 42042 --print-reply body sends:
GET / HTTP/1.1
User-Agent: httperf/0.9.0
Host: localhost
And here's my server's response:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Length: 18
12
Hello World 1
0
httpref promptly prints out the response, but then just sits there, neither side closing the connection and httpref not exiting.
Where's my bug?
From RFC 2616, section 8.1.2:
A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
I am using a 3G UMTS connection. I am trying to implement HTTP tunneling to a server of mine
which listens on port 80 (this is done in order to bypass client's firewall). The problem is that the ISP's proxy server supports HTTP/1.0 which doesn't support persistent HTTP connection.
As a result, after one http request/response iteration between my client/server the ISP's proxy tears down the underlying TCP connection.
my client receives the following HTTP response:
HTTP/1.0 200 OK
Content-Type: application/octet-stream
Content-Length: yyy
X-Cache: MISS from ipmr5
Proxy-Connection: close
Content data
while my server actually sends:
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Type: application/octet-stream
Content-Length: yyy
Content data
Is there any workaround?
You could always use HTTPS. You will lose any benefits offered by the proxies (such as caching), but all of your HTTP headers will arrive at the server exactly as you sent them.
HTTP 1.0 proxies (which it seems your ISP uses) shouldn't be used in connection with Connection: Keep-Alive for persistent connections. The reasons for this are outlined in RFC-2068 (section 19.7.1). The short version, basically, is that your server is sending an invalid header for the kind of proxy you are using.