If you look at section 3 above we see that Client advised BIG-IP that its Initial Window Size was 1073741824. There are other common frame types and in my capture the one that came up was WINDOW_UPDATE. Appendix A - Other common frame types 5.1 WINDOW_UPDATE If there was payload it would be carried inside DATA frame type but as this is just a HEAD request then no DATA frame follows.ĥ. For HTTP/2 GET/HEAD requests there is a specific frame type called HEADERS which as the name implies carries HTTP/2 header information. Yes, Magic frame is always the same.Įnd-points are also supposed to ACK the receipt of SETTINGS frame from the other peer and the way they do it is by responding with another empty SETTINGS frame with ACK flag set:Ĭonnection-wise we're all set now.
Wireshark http post plus#
Server side (BIG-IP in this case) sends SETTINGS frame which counts as confirmation that HTTP/2 is being used plus any flow control configuration we want our peer to honour:Ĭlient sends Magic frame to confirm HTTP/2 is being used and then SETTINGS with its requirements for the connection. Think of it as something that has to take place like Client Hello and Server Hello in SSL for example. HTTP/2 is negotiated during SSL handshake in Application Layer Protocol Negotiation ( RFC 7301) SSL extension like this:Ĭlient says which protocol(s) it supports and server responds which one it picked (in this case it's HTTP/2!). Here's packet capture (in case you want to follow along): http2-test-v1.zip Note: 10.199.3.44 is my virtual server with HTTP/2 profile applied. The packet capture taken below was the result of the following curl command issued from my ubuntu Linux client (I could've used a browser instead): Confirmation of which protocol will be used I'll just issue a HEAD request and later on a GET request and we'll see how it looks like on Wireshark.įor more info about HTTP/2 profile and HTTP/2 protocol itself you can read the article I published on AskF5 and Jason's DevCentral article: What is HTTP Part X - HTTP/2. It's a simple test and here's the topology: It turns out Wireshark is a perfect tool for me to do just that. Some people find it easier to do a "test drive" first to learn how a new protocol works in its simplest form and only then read the RFC.