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
Related
I'm writing a simple app to determine if certain websites support http/2.
Based on what I've read in the draft:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-07#section-3.2
I should be able to do a get request such as
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
and then if they support http/2 the response should be something like:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: HTTP/2.0
[ HTTP/2.0 connection ...
I'm trying to understand exactly what the value of the HTTP2-Settings request header should be.
I'm hoping someone can explain what information should be included with an example.
HTTP/2 has reached the status of official standard.
You will have very little luck in determining whether websites support HTTP/2 by using the cleartext upgrade mechanism.
The reason is that browsers don't support this style of upgrade to HTTP/2 (they all prefer using ALPN over TLS), and therefore neither servers do.
[Disclaimer, I am a Jetty committer and the Jetty HTTP/2 implementor].
For example, Jetty does support this style of upgrade (and even direct HTTP/2), see for example these tests, but we don't deploy it on our own website, https://webtide.com, for the reasons above.
You don't need to send something in this upgrade SETTINGS frame, you want to only send it if you want to configure the server before it gets a chance to speak back HTTP/2 to you, but typically default values are ok.
Remember that, as part of the connection preface, the client has to send another SETTINGS frame, which also can be empty or contain configuration parameters. Typically HTTP/2 client APIs such as the Jetty HTTP2Client will allow you to easily configure the SETTINGS frame that is part of the preface, because it's what will be use in both the upgrade mechanism and the ALPN mechanism.
A minimal, valid value for the HTTP2-Settings header is the empty string:
GET / HTTP/1.1
Host: host
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings:
User-Agent: whatever
Otherwise you need to create a SETTINGS frame payload (only the bytes defined here, and hence without the 9 octet frame header defined here), and then convert those bytes using base64 as defined here.
For the purpose of your tests, an empty HTTP2-Settings header will do, but as I said, you will most certainly not detecting whether a website supports HTTP/2: your upgrade will fail, but the website may well support HTTP/2 over TLS via ALPN.
This site http://nghttp2.org/ accepts non encrypted HTTP2 (h2c) connections, so doing:
GET / HTTP/1.1
Host: nghttp2.org
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings:
User-Agent: whatever
As suggested by sbordet does produce a "101 Switching Protocols" response from the server.
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.
Where can I see a list of all necessary headers for HTTP requests (for example, GET and POST)?
If you use HTTP/1.1 GET, it is only required to specify the Host: option, like this:
GET / HTTP/1.1
Host: www.google.com
If you use HTTP/1.0, you don't even need the Host:.
If you want to use a POST-query with form-data, you may look at this answer: Sending a file via POST using raw HTTP (Putty)
Here is the specification for all HTTP/1.1-header fields:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html . You can tak a look at the Host: option in point 14.23 in this specification.
Based on w3.org:
A client MUST include a Host header field in all HTTP/1.1 request
messages
and that's the only required field ever.
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.