# Translating between HTTP/1 and HTTP/2

DevFeed: [Translating between HTTP/1 and HTTP/2](<https://devfeed.tech/articles/translating-between-http-1-and-http-2-19099.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/translating-http-2-into-http-1/>)

Author: HTTP Toolkit; Tim Perry

Published: 2020-07-15T14:00:00Z

Content type: article

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [networking](<https://devfeed.tech/topics/networking.md>), [client](<https://devfeed.tech/topics/client.md>), [servers](<https://devfeed.tech/topics/servers.md>)

Tags: [http](<https://devfeed.tech/tags/http.md>), [network](<https://devfeed.tech/tags/network.md>), [proxy](<https://devfeed.tech/tags/proxy.md>), [request](<https://devfeed.tech/tags/request.md>), [responses](<https://devfeed.tech/tags/responses.md>), [server](<https://devfeed.tech/tags/server.md>), [standards](<https://devfeed.tech/tags/standards.md>)

## AI overview

An article explains the semantic and practical differences between HTTP/1.1 and HTTP/2, focusing on how developers should handle translation between the protocols. It notes that the request-response model and most method and status-code meanings remain unchanged, while more complex cases require attention to protocol differences.

## Source excerpt

Semantically, what changed in HTTP/2? Multiplexed connections, binary frames, header compression - all the headline changes are syntactic and network format changes, rather than fundamental changes to the concept. As a developer building on top of this, you can often ignore the low-level syntax of network protocols like this, and just think about the meaning of each message (the semantics) rather than byte-by-byte how it's sent between computers. Semantically though, while HTTP/2 is built on top of the ideas of HTTP/1.1, and the HTTP/2 spec is at pains to emphasize that it is not redefining HTTP's semantics, there are a few real-world semantic differences you need to use it effectively (and with HTTP/2 now in use on nearly 50% of the top 10 million webservers, you really do need to know how it works). This matters when building anything non-trivial on HTTP/2, but especially matters if your application does need to translate between the two, e.g. as a proxy or from a cache, and it's important to understand if you want to reliably handle requests in both protocols using the same code. The more things change, the more they stay the same Let's start with what doesn't change. Firstly, the core communication model is still a request from a client followed by a response from the server. Requests have a method like GET, a URL, some headers, and optionally a body. Responses have a status code (200, 404...), their own headers, and their own body. Most HTTP methods and status codes still have the same fundamental meanings. You can write code that takes a request, looks at the method & URL to decide what to do, and sends back a response with a status code and the data requested, and most frameworks will make that work for you automatically. For basic HTTP handling like that, you can just enable HTTP/2 in your server of choice, and you're golden. Once you get into anything more complex though, you can run into some interesting issues. Let's dig into the differences: Status message