# How HTTP Toolkit handles HTTP and HTTPS traffic on a single port

DevFeed: [How HTTP Toolkit handles HTTP and HTTPS traffic on a single port](<https://devfeed.tech/articles/one-port-to-rule-them-all-19071.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/http-https-same-port/>)

Author: HTTP Toolkit; Tim Perry

Published: 2021-04-15T16:45:00Z

Content type: article

Language: en

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

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [interception](<https://devfeed.tech/topics/interception.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [servers](<https://devfeed.tech/topics/servers.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>)

Tags: [http](<https://devfeed.tech/tags/http.md>), [interception](<https://devfeed.tech/tags/interception.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [proxy](<https://devfeed.tech/tags/proxy.md>), [request](<https://devfeed.tech/tags/request.md>), [responses](<https://devfeed.tech/tags/responses.md>), [tls](<https://devfeed.tech/tags/tls.md>)

## AI overview

HTTP Toolkit uses one incoming TCP port to accept multiple HTTP and HTTPS formats, including HTTP/1.x, HTTP/2, and TLS connections. It combines direct requests, explicit proxying, redirection, and tunneling so traffic can be intercepted and handled by configured rules.

## Source excerpt

Traditionally, a TCP port has a single server listening for incoming connections, and that server expects you to send messages in the right protocol for that port. For HTTP, it's normally a web server that'll send you a response directly, or some kind of proxy that will pass all requests through to another server, and then pass the responses back. This is boring. What if you could accept everything, from proxied HTTPS to plain-text HTTP/1.0, all on a single port? HTTP Toolkit acts as an HTTP(S) proxy for debugging and interception. With all the possible combinations of clients and configurations, tools like this can be complicated to set up, and getting everything working and properly intercepted is a common pain point. To make setup as easy as possible, HTTP Toolkit uses a single incoming port for absolutely everything, for every widespread HTTP format, for both HTTP & HTTPS, for both direct and proxied requests. Specifically, on one single port it accepts: Plain HTTP/1.* (1.1, or 1.0 if you just can't quit the 90s) HTTP/1.* over TLS (HTTPS) Plain-text HTTP/2 with prior knowledge Plain-text HTTP/2, upgraded on the first request by an Upgrade header HTTP/2 over TLS (HTTPS) negotiated via ALPN These can then all be combined to suit your tastes with a selection of ways to make your actual HTTP request: Make a direct request to HTTP Toolkit's URL as if it were a server, and mock a response for that in the app (GET /). Proxy through HTTP Toolkit explicitly in plain text (GET http://example.com/). Redirect unsuspecting traffic that's not aware of the proxy to HTTP Toolkit, to transparently proxy traffic elsewhere: GET / Host: example.com Tunnel traffic by connecting with HTTP/1.1, sending CONNECT example.com:443 to make the connection into a tunnel to another server, and then doing any of the above within that tunnel. Tunnel traffic within a single HTTP/2 stream, by sending a CONNECT request to convert that one stream into a tunnel, and then doing any of the above again