In a hospital lab, HTTP/2 rides TCP port 443 in the clear, and a request pseudo-header carries the path. What changed relative to an HTTP/1 request line?
Select an answer to reveal the explanation.
Short Explanation
You can still read the method and path in HTTP/2; the path is carried in a pseudo-header instead of an HTTP/1 request line. The bytes look different, but the request information remains available to you. This TCP stream does not put the path in UDP, the Ethernet header, or the IPv4 checksum.
Full Explanation
In this hospital lab, the HTTP/2 session uses TCP port 443 and is readable without decryption. Unlike an HTTP/1 request line, HTTP/2 carries the method and path in named pseudo-header fields, including the path field, so you can still read both. The correct description is that the path sits in an HTTP/2 pseudo-header and the analyst still reads the method and path. Saying HTTP/2 runs as UDP and the path is absent does not fit this TCP stream. Ethernet headers identify local delivery; they do not carry an HTTP path, and moving the path there would not leave the application layer behind. The IPv4 header checksum covers header integrity; it does not store a URL path, so it cannot carry the path in every packet. Exam caveat: HTTP/3 uses QUIC over UDP, but this capture is HTTP/2 over TCP; do not confuse the protocols or infer that the path comes from a frame layout. Practical check: display the clear HTTP/2 headers in the capture, then read the method and path from the request pseudo-header.