{ "archive_path": "archive/1791021967.728559", "base_url": "blog.cloudflare.com/announcing-cloudflare-ohttp-gateway", "basename": "", "bookmarked_date": "2026-10-03 10:06", "canonical": { "archive_org_path": "https://web.archive.org/web/blog.cloudflare.com/announcing-cloudflare-ohttp-gateway", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=blog.cloudflare.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": "blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/index.html" }, "domain": "blog.cloudflare.com", "extension": "", "hash": "130RV0G6PG6KPXAZXA64", "history": { "archive_org": [], "dom": [], "favicon": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=blog.cloudflare.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T16:26:37.276084+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:36.585089+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=blog.cloudflare.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T10:07:14.275865+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:13.711763+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=blog.cloudflare.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T19:27:22.407901+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:21.608967+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T16:26:37.694948+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:37.282229+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T10:07:14.697478+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:14.284810+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T19:27:22.838991+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:22.412829+00:00", "status": "succeeded" } ], "htmltotext": [], "media": [], "mercury": [ { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-03T16:26:47.083562+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:42.069960+00:00", "status": "succeeded" }, { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-03T10:07:28.664045+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:22.623333+00:00", "status": "succeeded" }, { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-03T19:27:31.919502+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:26.331051+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmpwjhk3evt", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-03T16:26:42.057537+00:00", "index_texts": [ "Today, end users carry too much\u00a0of the burden of online privacy. To avoid third-party trackers or targeted ads, users are instructed to use a VPN, disable cookies, or install adblockers. Meanwhile, some app developers end up knowing more about their users than they\u2019d care to: a typical client-server exchange creates a trail of user data, like the client\u2019s IP address\u00a0or TLS fingerprint. This level of visibility can be a burden.That\u2019s why Cloudflare builds infrastructure that helps developers bake privacy into their apps. Oblivious HTTP (OHTTP) is an IETF standard\u00a0designed to enable app backends to receive HTTP requests without seeing user IP addresses.This fall, we\u2019re launching the Cloudflare OHTTP Gateway. Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks. Register through our form\u00a0to join our waitlist. Read on to learn more.Expanding our OHTTP product suiteWith OHTTP, requests travel through two independently-operated hops: a relay and a gateway. An OHTTP relay blindly forwards encrypted requests in order to hide client identifiers from app servers. An OHTTP gateway performs the cryptographic work of decapsulating encrypted requests and encapsulating responses such that app servers can handle OHTTP requests as if they were plain HTTP. The separation of trust between relay and gateway is critical: it ensures that no single party sees both client identifiers and request contents.In 2022, we launched an OHTTP relay product, Privacy Gateway. Privacy Gateway enables our customers to offer more privacy-preserving experiences to their users. For example, Flo Health uses OHTTP for their app\u2019s Anonymous Mode, and Apple\u2019s Private Cloud Compute\u00a0uses OHTTP to disassociate AI inference requests from user identities. But customers who are already protecting their servers behind Cloudflare can\u2019t also use a Cloudflare-operated relay \u2014 they need an OHTTP gateway instead.With the existing Cloudflare OHTTP Relay, customers must bring their own Gateway to preserve a separation of trust.In our experience running OHTTP relays, we\u2019ve seen how difficult it can be to build and operate a secure, performant OHTTP gateway at scale. Today, we\u2019re launching\u00a0the closed beta for our self-serve Cloudflare OHTTP Gateway. We\u2019re also renaming our\u00a0\u201cPrivacy Gateway\u201d to \u201cCloudflare OHTTP Relay\u201d to better distinguish the two products.\u00a0Now, customers who want an OHTTP architecture with the necessary separation of trust have two options:Use Cloudflare\u2019s OHTTP Relay (formerly Cloudflare Privacy Gateway) and run your gateway yourself. This is best if your application servers are hosted off Cloudflare, and you\u2019re able to run your own OHTTP gateway.Use Cloudflare\u2019s new OHTTP Gateway with a third-party relay. This is best if your app servers are already behind Cloudflare (on our CDN or Workers, for example), if you\u2019re accepting OHTTP requests from a third party (like Apple\u2019s LiveCallerID), or if you want a managed gateway to minimize latency and operational overhead. \u00a0We\u2019re working to raise the bar for privacy across the Internet, and we believe that protocols like OHTTP can help \u2014 if we make them easy enough to adopt. It\u2019s always been our goal to expand our OHTTP product suite and make our trusted privacy infrastructure accessible to a broader swath of the Internet.Why we built the Cloudflare OHTTP GatewaySince\u00a0we launched our OHTTP Relay product,\u00a0we\u2019ve observed a few things.First, we\u2019ve seen that there's a growing appetite among developers for accessible, usable privacy infrastructure. Developers of privacy-oriented apps want to bake network privacy into their applications by default, but doing so remains harder than it should be. \u00a0Second, we\u2019ve learned that building and operating an OHTTP gateway can be tough for customers. Any proxying architecture introduces some latency because requests must travel an extra hop or two around the Internet. Combine that with the cost to decrypt requests and encrypt responses, and the latency hit of a homegrown OHTTP setup can be significant. We\u2019re well-positioned to solve this problem: the same building blocks that enable us to operate fast, reliable privacy infrastructure for products like 1.1.1.1\u00a0and iCloud Private Relay\u00a0make us a good home for an OHTTP gateway. Because of Cloudflare\u2019s anycast\u00a0approach, our OHTTP Gateway will run on every server on Cloudflare\u2019s global edge network, minimizing latency in relay-to-gateway hops. If you use our CDN, user requests can be decrypted by our Gateway and resolved by your app servers on the same Cloudflare metals, saving gateway-to-origin latency.Finally, recall that OHTTP\u2019s privacy model\u00a0requires\u00a0that the relay and app server be operated by separate, non-colluding parties. We want to provide our customers with the best possible range of options for their privacy infrastructure. Before, developers who protected their app servers behind Cloudflare weren\u2019t able to use our OHTTP Relay, because Cloudflare would see both client metadata and the decrypted contents of requests, breaking OHTTP\u2019s privacy model. Now, developers can choose whether a Cloudflare OHTTP Relay or Gateway is a better fit for their architecture.A primer on OHTTPA typical interaction between a client and application server reveals information about the client. When a client and app server talk to one another, the app server learns the client\u2019s IP address because each packet in which data is sent is labeled with a source IP \u2014 similar to the \u201cfrom\u201d label on an envelope. App servers can also \u201cfingerprint\u201d a client based on attributes like supported TLS versions or cipher suites. These signals make it possible for app servers to link multiple requests back to the same user.But what if I wanted to build an app that really doesn\u2019t know much about my users? For example: Flo Health wanted to build an Anonymous Mode\u00a0to enable users to access personal health data without it being linkable to possible user identifiers. \u00a0OHTTP introduces a proxy, called a \u201crelay,\u201d that forwards requests and responses between client and app server to obfuscate the client\u2019s identity from the app server. The relay sees client identifiers like IP address and TLS fingerprint, but strips them\u00a0before forwarding on requests. This prevents app servers from linking multiple requests back to the same user, and means that request contents can\u2019t be associated with the user\u2019s IP address.For example, a regular client-server exchange might reveal the following information about a client:- ipAddress: 192.0.2.33 # the client\u2019s IP address \n- ASN: 7922\n- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique\n- tlsVersion: TLSv1.3\n- Country: US\n- Region: California # the client's location\n- City: CampbellA request first sent through an OHTTP relay would reveal only the relay\u2019s information to the app server receiving the request:- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint \n- ASN: 18 \n- tlsCipher: AEAD-AES-128-GCM-SHA256 \n- tlsVersion: TLSv1.3 \n- Country: US\n- Region: Texas # the relay's location\n- City: AustinThis means that for each request, the app server doesn\u2019t learn the location and TLS fingerprint of the end user. Plus, if many different users are sending requests through the relay, the app server won\u2019t be able to distinguish which requests are coming from whom, limiting their ability to trace app activity back to a single end user. This creates a strong privacy boundary.What really differentiates OHTTP from a basic forwarding proxy, however, is the encryption of data between client and app server. Requests and responses are encapsulated using Hybrid Public Key Encryption\u00a0(HPKE)\u00a0such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A \u201cgateway\u201d sits between the relay and app server to handle all of this cryptography \u2014 decapsulating requests, encapsulating responses \u2014 and the app server handles only plain HTTP. \u00a0This creates a \u201cdouble-blind\u201d privacy model: the relay sees only client identifiers; the gateway and app server see only request contents; no party sees both.A diagram showing how requests flow from end users through the OHTTP Gateway to app servers. A response from app servers follows the same path in reverse to the end user. Note that with the Gateway, you can choose whether or not to put your servers behind Cloudflare.How we built the OHTTP GatewayIn building our OHTTP gateway-as-a-service, our goal is to bring our secure, performant privacy infrastructure to a broader swath of the Internet. Performance and easy onboarding are critical. So, we built our Gateway\u00a0as a flexible service deployed across our global network. With just a couple of clicks, you can enable the Gateway on your zone and start sending OHTTP to https://your-zone.com/.well-known/ohttp-gateway. We\u2019ll scale the service up and down automatically, so you don\u2019t need to worry about capacity.We had a few other user needs in mind, informed by the pain points we\u2019d seen OHTTP Relay customers run into when operating their own OHTTP gateways.First: We wanted to abstract away as much of the complexity of OHTTP as possible for your app servers. We wanted developers to be able to start receiving OHTTP while continuing to accept regular HTTP traffic if they chose. So, we designed the Gateway as a feature of your\u00a0zone, where clients send well-formatted\u00a0OHTTP requests to a /.well-known/ohttp-gateway\u00a0endpoint on your zone. We support both standard and chunked OHTTP\u00a0\u2014 and we recommend using chunked OHTTP for better performance, because it enables us to process requests incrementally (in \u201cchunks\u201d).Our Gateway service will intercept each request, decrypt it, issue a subrequest to your app server, and return an encrypted response to the client. All non-OHTTP requests will travel to your server without invoking the Gateway.Binding your Gateway to your zone also enables us to protect your Gateway from abuse. A client sending requests to your zone `example.com` may send to `foo.example.com` or `bar.example.com`, but not wikipedia.com. Without you needing to worry about it, this prevents unauthorized clients from using your zone as a way to target other domains.Second: Seamless key management is critical.\u00a0Gateways need to maintain a public HPKE key configuration to enable clients to encrypt requests, but managing keys securely is a challenge. So, we designed the Gateway to fully manage all keys for customers, and to serve public keys as responses to GET requests to \u00a0/.well-known/ohttp-gateway. For stronger privacy, clients can download keys over a different IP than they request the gateway.Third: Gateways need to be able to authenticate relays. Because the Gateway (by design) knows very little about the client sending a given request, it places trust in the relay to authenticate clients and forward traffic responsibly. But how do you ensure that only trusted relays can send traffic to your gateway?We designed the Gateway such that\u00a0Cloudflare Access, Cloudflare\u2019s zero trust network access product, runs before requests are decrypted, enabling you to use any standard Access policies\u00a0to authenticate incoming traffic and protect your Gateway from abuse. Options include mutual TLS, static service credentials, and custom external logic.Finally: Mistakes happen, and we anticipated that customers might accidentally break OHTTP\u2019s privacy model by running both their relay and gateway on Cloudflare. So, to preserve OHTTP\u2019s separation of trust and ensure that Cloudflare never sees both client identities and decrypted inner requests, our Gateway will refuse\u00a0to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare.When is the OHTTP Gateway a better fit than the OHTTP Relay?If you want to use Cloudflare\u2019s OHTTP product suite, but you\u2019re wondering why you\u2019d pick Cloudflare\u2019s OHTTP Gateway instead of the OHTTP Relay, here are a couple of considerations.First, do you want your app servers on Cloudflare \u2013 behind our CDN or built on Workers, for example? If so, the OHTTP Gateway is a better fit to ensure adherence to OHTTP\u2019s privacy model.Second, what\u2019s your use case? If you want to receive OHTTP requests from a third-party client and relay \u2014 to use\u00a0Apple\u2019s LiveCallerID\u00a0SDK, for example \u2014 then the OHTTP Gateway is likely the better solution for you. \u00a0Getting startedIf you have a feature request or would like to register for our waitlist, so we can notify you when the product launches, sign up here.Then, you\u2019ll need to implement an OHTTP client. See ohttp.info\u00a0or our sample client library\u00a0for some examples to help you get started. One flag as you build the client: OHTTP provides privacy at the network level, and doesn\u2019t touch the inner request body. So, to preserve user privacy, it\u2019s up to you not to send identifying information (e.g. a user\u2019s email address or username) in the request body.Next, you\u2019ll need to bring your own relay. Relays can run on any infrastructure provider, and they\u2019re simple: here\u2019s some sample code. The challenge and the reason you might want a dedicated OHTTP relay provider, is to verifiably promise to your users that you won\u2019t inspect logs with client identifiers. Otherwise, you\u2019d be able to correlate clients at the relay with decrypted requests at your app servers. \u00a0Finally, once your OHTTP deployment is live, check out our pvcli client\u00a0to help with testing and debugging. We\u2019re excited to bring accessible privacy infrastructure to developers everywhere. Reach out to us\u00a0if you\u2019d like to try out the new OHTTP Gateway and raise the bar for privacy online." ], "output": "readability", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:38.200611+00:00", "status": "succeeded" }, { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmp5fpt2md6", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-03T10:07:22.610225+00:00", "index_texts": [ "Today, end users carry too much\u00a0of the burden of online privacy. To avoid third-party trackers or targeted ads, users are instructed to use a VPN, disable cookies, or install adblockers. Meanwhile, some app developers end up knowing more about their users than they\u2019d care to: a typical client-server exchange creates a trail of user data, like the client\u2019s IP address\u00a0or TLS fingerprint. This level of visibility can be a burden.That\u2019s why Cloudflare builds infrastructure that helps developers bake privacy into their apps. Oblivious HTTP (OHTTP) is an IETF standard\u00a0designed to enable app backends to receive HTTP requests without seeing user IP addresses.This fall, we\u2019re launching the Cloudflare OHTTP Gateway. Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks. Register through our form\u00a0to join our waitlist. Read on to learn more.Expanding our OHTTP product suiteWith OHTTP, requests travel through two independently-operated hops: a relay and a gateway. An OHTTP relay blindly forwards encrypted requests in order to hide client identifiers from app servers. An OHTTP gateway performs the cryptographic work of decapsulating encrypted requests and encapsulating responses such that app servers can handle OHTTP requests as if they were plain HTTP. The separation of trust between relay and gateway is critical: it ensures that no single party sees both client identifiers and request contents.In 2022, we launched an OHTTP relay product, Privacy Gateway. Privacy Gateway enables our customers to offer more privacy-preserving experiences to their users. For example, Flo Health uses OHTTP for their app\u2019s Anonymous Mode, and Apple\u2019s Private Cloud Compute\u00a0uses OHTTP to disassociate AI inference requests from user identities. But customers who are already protecting their servers behind Cloudflare can\u2019t also use a Cloudflare-operated relay \u2014 they need an OHTTP gateway instead.With the existing Cloudflare OHTTP Relay, customers must bring their own Gateway to preserve a separation of trust.In our experience running OHTTP relays, we\u2019ve seen how difficult it can be to build and operate a secure, performant OHTTP gateway at scale. Today, we\u2019re launching\u00a0the closed beta for our self-serve Cloudflare OHTTP Gateway. We\u2019re also renaming our\u00a0\u201cPrivacy Gateway\u201d to \u201cCloudflare OHTTP Relay\u201d to better distinguish the two products.\u00a0Now, customers who want an OHTTP architecture with the necessary separation of trust have two options:Use Cloudflare\u2019s OHTTP Relay (formerly Cloudflare Privacy Gateway) and run your gateway yourself. This is best if your application servers are hosted off Cloudflare, and you\u2019re able to run your own OHTTP gateway.Use Cloudflare\u2019s new OHTTP Gateway with a third-party relay. This is best if your app servers are already behind Cloudflare (on our CDN or Workers, for example), if you\u2019re accepting OHTTP requests from a third party (like Apple\u2019s LiveCallerID), or if you want a managed gateway to minimize latency and operational overhead. \u00a0We\u2019re working to raise the bar for privacy across the Internet, and we believe that protocols like OHTTP can help \u2014 if we make them easy enough to adopt. It\u2019s always been our goal to expand our OHTTP product suite and make our trusted privacy infrastructure accessible to a broader swath of the Internet.Why we built the Cloudflare OHTTP GatewaySince\u00a0we launched our OHTTP Relay product,\u00a0we\u2019ve observed a few things.First, we\u2019ve seen that there's a growing appetite among developers for accessible, usable privacy infrastructure. Developers of privacy-oriented apps want to bake network privacy into their applications by default, but doing so remains harder than it should be. \u00a0Second, we\u2019ve learned that building and operating an OHTTP gateway can be tough for customers. Any proxying architecture introduces some latency because requests must travel an extra hop or two around the Internet. Combine that with the cost to decrypt requests and encrypt responses, and the latency hit of a homegrown OHTTP setup can be significant. We\u2019re well-positioned to solve this problem: the same building blocks that enable us to operate fast, reliable privacy infrastructure for products like 1.1.1.1\u00a0and iCloud Private Relay\u00a0make us a good home for an OHTTP gateway. Because of Cloudflare\u2019s anycast\u00a0approach, our OHTTP Gateway will run on every server on Cloudflare\u2019s global edge network, minimizing latency in relay-to-gateway hops. If you use our CDN, user requests can be decrypted by our Gateway and resolved by your app servers on the same Cloudflare metals, saving gateway-to-origin latency.Finally, recall that OHTTP\u2019s privacy model\u00a0requires\u00a0that the relay and app server be operated by separate, non-colluding parties. We want to provide our customers with the best possible range of options for their privacy infrastructure. Before, developers who protected their app servers behind Cloudflare weren\u2019t able to use our OHTTP Relay, because Cloudflare would see both client metadata and the decrypted contents of requests, breaking OHTTP\u2019s privacy model. Now, developers can choose whether a Cloudflare OHTTP Relay or Gateway is a better fit for their architecture.A primer on OHTTPA typical interaction between a client and application server reveals information about the client. When a client and app server talk to one another, the app server learns the client\u2019s IP address because each packet in which data is sent is labeled with a source IP \u2014 similar to the \u201cfrom\u201d label on an envelope. App servers can also \u201cfingerprint\u201d a client based on attributes like supported TLS versions or cipher suites. These signals make it possible for app servers to link multiple requests back to the same user.But what if I wanted to build an app that really doesn\u2019t know much about my users? For example: Flo Health wanted to build an Anonymous Mode\u00a0to enable users to access personal health data without it being linkable to possible user identifiers. \u00a0OHTTP introduces a proxy, called a \u201crelay,\u201d that forwards requests and responses between client and app server to obfuscate the client\u2019s identity from the app server. The relay sees client identifiers like IP address and TLS fingerprint, but strips them\u00a0before forwarding on requests. This prevents app servers from linking multiple requests back to the same user, and means that request contents can\u2019t be associated with the user\u2019s IP address.For example, a regular client-server exchange might reveal the following information about a client:- ipAddress: 192.0.2.33 # the client\u2019s IP address \n- ASN: 7922\n- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique\n- tlsVersion: TLSv1.3\n- Country: US\n- Region: California # the client's location\n- City: CampbellA request first sent through an OHTTP relay would reveal only the relay\u2019s information to the app server receiving the request:- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint \n- ASN: 18 \n- tlsCipher: AEAD-AES-128-GCM-SHA256 \n- tlsVersion: TLSv1.3 \n- Country: US\n- Region: Texas # the relay's location\n- City: AustinThis means that for each request, the app server doesn\u2019t learn the location and TLS fingerprint of the end user. Plus, if many different users are sending requests through the relay, the app server won\u2019t be able to distinguish which requests are coming from whom, limiting their ability to trace app activity back to a single end user. This creates a strong privacy boundary.What really differentiates OHTTP from a basic forwarding proxy, however, is the encryption of data between client and app server. Requests and responses are encapsulated using Hybrid Public Key Encryption\u00a0(HPKE)\u00a0such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A \u201cgateway\u201d sits between the relay and app server to handle all of this cryptography \u2014 decapsulating requests, encapsulating responses \u2014 and the app server handles only plain HTTP. \u00a0This creates a \u201cdouble-blind\u201d privacy model: the relay sees only client identifiers; the gateway and app server see only request contents; no party sees both.A diagram showing how requests flow from end users through the OHTTP Gateway to app servers. A response from app servers follows the same path in reverse to the end user. Note that with the Gateway, you can choose whether or not to put your servers behind Cloudflare.How we built the OHTTP GatewayIn building our OHTTP gateway-as-a-service, our goal is to bring our secure, performant privacy infrastructure to a broader swath of the Internet. Performance and easy onboarding are critical. So, we built our Gateway\u00a0as a flexible service deployed across our global network. With just a couple of clicks, you can enable the Gateway on your zone and start sending OHTTP to https://your-zone.com/.well-known/ohttp-gateway. We\u2019ll scale the service up and down automatically, so you don\u2019t need to worry about capacity.We had a few other user needs in mind, informed by the pain points we\u2019d seen OHTTP Relay customers run into when operating their own OHTTP gateways.First: We wanted to abstract away as much of the complexity of OHTTP as possible for your app servers. We wanted developers to be able to start receiving OHTTP while continuing to accept regular HTTP traffic if they chose. So, we designed the Gateway as a feature of your\u00a0zone, where clients send well-formatted\u00a0OHTTP requests to a /.well-known/ohttp-gateway\u00a0endpoint on your zone. We support both standard and chunked OHTTP\u00a0\u2014 and we recommend using chunked OHTTP for better performance, because it enables us to process requests incrementally (in \u201cchunks\u201d).Our Gateway service will intercept each request, decrypt it, issue a subrequest to your app server, and return an encrypted response to the client. All non-OHTTP requests will travel to your server without invoking the Gateway.Binding your Gateway to your zone also enables us to protect your Gateway from abuse. A client sending requests to your zone `example.com` may send to `foo.example.com` or `bar.example.com`, but not wikipedia.com. Without you needing to worry about it, this prevents unauthorized clients from using your zone as a way to target other domains.Second: Seamless key management is critical.\u00a0Gateways need to maintain a public HPKE key configuration to enable clients to encrypt requests, but managing keys securely is a challenge. So, we designed the Gateway to fully manage all keys for customers, and to serve public keys as responses to GET requests to \u00a0/.well-known/ohttp-gateway. For stronger privacy, clients can download keys over a different IP than they request the gateway.Third: Gateways need to be able to authenticate relays. Because the Gateway (by design) knows very little about the client sending a given request, it places trust in the relay to authenticate clients and forward traffic responsibly. But how do you ensure that only trusted relays can send traffic to your gateway?We designed the Gateway such that\u00a0Cloudflare Access, Cloudflare\u2019s zero trust network access product, runs before requests are decrypted, enabling you to use any standard Access policies\u00a0to authenticate incoming traffic and protect your Gateway from abuse. Options include mutual TLS, static service credentials, and custom external logic.Finally: Mistakes happen, and we anticipated that customers might accidentally break OHTTP\u2019s privacy model by running both their relay and gateway on Cloudflare. So, to preserve OHTTP\u2019s separation of trust and ensure that Cloudflare never sees both client identities and decrypted inner requests, our Gateway will refuse\u00a0to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare.When is the OHTTP Gateway a better fit than the OHTTP Relay?If you want to use Cloudflare\u2019s OHTTP product suite, but you\u2019re wondering why you\u2019d pick Cloudflare\u2019s OHTTP Gateway instead of the OHTTP Relay, here are a couple of considerations.First, do you want your app servers on Cloudflare \u2013 behind our CDN or built on Workers, for example? If so, the OHTTP Gateway is a better fit to ensure adherence to OHTTP\u2019s privacy model.Second, what\u2019s your use case? If you want to receive OHTTP requests from a third-party client and relay \u2014 to use\u00a0Apple\u2019s LiveCallerID\u00a0SDK, for example \u2014 then the OHTTP Gateway is likely the better solution for you. \u00a0Getting startedIf you have a feature request or would like to register for our waitlist, so we can notify you when the product launches, sign up here.Then, you\u2019ll need to implement an OHTTP client. See ohttp.info\u00a0or our sample client library\u00a0for some examples to help you get started. One flag as you build the client: OHTTP provides privacy at the network level, and doesn\u2019t touch the inner request body. So, to preserve user privacy, it\u2019s up to you not to send identifying information (e.g. a user\u2019s email address or username) in the request body.Next, you\u2019ll need to bring your own relay. Relays can run on any infrastructure provider, and they\u2019re simple: here\u2019s some sample code. The challenge and the reason you might want a dedicated OHTTP relay provider, is to verifiably promise to your users that you won\u2019t inspect logs with client identifiers. Otherwise, you\u2019d be able to correlate clients at the relay with decrypted requests at your app servers. \u00a0Finally, once your OHTTP deployment is live, check out our pvcli client\u00a0to help with testing and debugging. We\u2019re excited to bring accessible privacy infrastructure to developers everywhere. Reach out to us\u00a0if you\u2019d like to try out the new OHTTP Gateway and raise the bar for privacy online." ], "output": "readability", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:18.901879+00:00", "status": "succeeded" }, { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmp8y9xs1xp", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-03T19:27:26.320825+00:00", "index_texts": [ "Today, end users carry too much\u00a0of the burden of online privacy. To avoid third-party trackers or targeted ads, users are instructed to use a VPN, disable cookies, or install adblockers. Meanwhile, some app developers end up knowing more about their users than they\u2019d care to: a typical client-server exchange creates a trail of user data, like the client\u2019s IP address\u00a0or TLS fingerprint. This level of visibility can be a burden.That\u2019s why Cloudflare builds infrastructure that helps developers bake privacy into their apps. Oblivious HTTP (OHTTP) is an IETF standard\u00a0designed to enable app backends to receive HTTP requests without seeing user IP addresses.This fall, we\u2019re launching the Cloudflare OHTTP Gateway. Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks. Register through our form\u00a0to join our waitlist. Read on to learn more.Expanding our OHTTP product suiteWith OHTTP, requests travel through two independently-operated hops: a relay and a gateway. An OHTTP relay blindly forwards encrypted requests in order to hide client identifiers from app servers. An OHTTP gateway performs the cryptographic work of decapsulating encrypted requests and encapsulating responses such that app servers can handle OHTTP requests as if they were plain HTTP. The separation of trust between relay and gateway is critical: it ensures that no single party sees both client identifiers and request contents.In 2022, we launched an OHTTP relay product, Privacy Gateway. Privacy Gateway enables our customers to offer more privacy-preserving experiences to their users. For example, Flo Health uses OHTTP for their app\u2019s Anonymous Mode, and Apple\u2019s Private Cloud Compute\u00a0uses OHTTP to disassociate AI inference requests from user identities. But customers who are already protecting their servers behind Cloudflare can\u2019t also use a Cloudflare-operated relay \u2014 they need an OHTTP gateway instead.With the existing Cloudflare OHTTP Relay, customers must bring their own Gateway to preserve a separation of trust.In our experience running OHTTP relays, we\u2019ve seen how difficult it can be to build and operate a secure, performant OHTTP gateway at scale. Today, we\u2019re launching\u00a0the closed beta for our self-serve Cloudflare OHTTP Gateway. We\u2019re also renaming our\u00a0\u201cPrivacy Gateway\u201d to \u201cCloudflare OHTTP Relay\u201d to better distinguish the two products.\u00a0Now, customers who want an OHTTP architecture with the necessary separation of trust have two options:Use Cloudflare\u2019s OHTTP Relay (formerly Cloudflare Privacy Gateway) and run your gateway yourself. This is best if your application servers are hosted off Cloudflare, and you\u2019re able to run your own OHTTP gateway.Use Cloudflare\u2019s new OHTTP Gateway with a third-party relay. This is best if your app servers are already behind Cloudflare (on our CDN or Workers, for example), if you\u2019re accepting OHTTP requests from a third party (like Apple\u2019s LiveCallerID), or if you want a managed gateway to minimize latency and operational overhead. \u00a0We\u2019re working to raise the bar for privacy across the Internet, and we believe that protocols like OHTTP can help \u2014 if we make them easy enough to adopt. It\u2019s always been our goal to expand our OHTTP product suite and make our trusted privacy infrastructure accessible to a broader swath of the Internet.Why we built the Cloudflare OHTTP GatewaySince\u00a0we launched our OHTTP Relay product,\u00a0we\u2019ve observed a few things.First, we\u2019ve seen that there's a growing appetite among developers for accessible, usable privacy infrastructure. Developers of privacy-oriented apps want to bake network privacy into their applications by default, but doing so remains harder than it should be. \u00a0Second, we\u2019ve learned that building and operating an OHTTP gateway can be tough for customers. Any proxying architecture introduces some latency because requests must travel an extra hop or two around the Internet. Combine that with the cost to decrypt requests and encrypt responses, and the latency hit of a homegrown OHTTP setup can be significant. We\u2019re well-positioned to solve this problem: the same building blocks that enable us to operate fast, reliable privacy infrastructure for products like 1.1.1.1\u00a0and iCloud Private Relay\u00a0make us a good home for an OHTTP gateway. Because of Cloudflare\u2019s anycast\u00a0approach, our OHTTP Gateway will run on every server on Cloudflare\u2019s global edge network, minimizing latency in relay-to-gateway hops. If you use our CDN, user requests can be decrypted by our Gateway and resolved by your app servers on the same Cloudflare metals, saving gateway-to-origin latency.Finally, recall that OHTTP\u2019s privacy model\u00a0requires\u00a0that the relay and app server be operated by separate, non-colluding parties. We want to provide our customers with the best possible range of options for their privacy infrastructure. Before, developers who protected their app servers behind Cloudflare weren\u2019t able to use our OHTTP Relay, because Cloudflare would see both client metadata and the decrypted contents of requests, breaking OHTTP\u2019s privacy model. Now, developers can choose whether a Cloudflare OHTTP Relay or Gateway is a better fit for their architecture.A primer on OHTTPA typical interaction between a client and application server reveals information about the client. When a client and app server talk to one another, the app server learns the client\u2019s IP address because each packet in which data is sent is labeled with a source IP \u2014 similar to the \u201cfrom\u201d label on an envelope. App servers can also \u201cfingerprint\u201d a client based on attributes like supported TLS versions or cipher suites. These signals make it possible for app servers to link multiple requests back to the same user.But what if I wanted to build an app that really doesn\u2019t know much about my users? For example: Flo Health wanted to build an Anonymous Mode\u00a0to enable users to access personal health data without it being linkable to possible user identifiers. \u00a0OHTTP introduces a proxy, called a \u201crelay,\u201d that forwards requests and responses between client and app server to obfuscate the client\u2019s identity from the app server. The relay sees client identifiers like IP address and TLS fingerprint, but strips them\u00a0before forwarding on requests. This prevents app servers from linking multiple requests back to the same user, and means that request contents can\u2019t be associated with the user\u2019s IP address.For example, a regular client-server exchange might reveal the following information about a client:- ipAddress: 192.0.2.33 # the client\u2019s IP address \n- ASN: 7922\n- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique\n- tlsVersion: TLSv1.3\n- Country: US\n- Region: California # the client's location\n- City: CampbellA request first sent through an OHTTP relay would reveal only the relay\u2019s information to the app server receiving the request:- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint \n- ASN: 18 \n- tlsCipher: AEAD-AES-128-GCM-SHA256 \n- tlsVersion: TLSv1.3 \n- Country: US\n- Region: Texas # the relay's location\n- City: AustinThis means that for each request, the app server doesn\u2019t learn the location and TLS fingerprint of the end user. Plus, if many different users are sending requests through the relay, the app server won\u2019t be able to distinguish which requests are coming from whom, limiting their ability to trace app activity back to a single end user. This creates a strong privacy boundary.What really differentiates OHTTP from a basic forwarding proxy, however, is the encryption of data between client and app server. Requests and responses are encapsulated using Hybrid Public Key Encryption\u00a0(HPKE)\u00a0such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A \u201cgateway\u201d sits between the relay and app server to handle all of this cryptography \u2014 decapsulating requests, encapsulating responses \u2014 and the app server handles only plain HTTP. \u00a0This creates a \u201cdouble-blind\u201d privacy model: the relay sees only client identifiers; the gateway and app server see only request contents; no party sees both.A diagram showing how requests flow from end users through the OHTTP Gateway to app servers. A response from app servers follows the same path in reverse to the end user. Note that with the Gateway, you can choose whether or not to put your servers behind Cloudflare.How we built the OHTTP GatewayIn building our OHTTP gateway-as-a-service, our goal is to bring our secure, performant privacy infrastructure to a broader swath of the Internet. Performance and easy onboarding are critical. So, we built our Gateway\u00a0as a flexible service deployed across our global network. With just a couple of clicks, you can enable the Gateway on your zone and start sending OHTTP to https://your-zone.com/.well-known/ohttp-gateway. We\u2019ll scale the service up and down automatically, so you don\u2019t need to worry about capacity.We had a few other user needs in mind, informed by the pain points we\u2019d seen OHTTP Relay customers run into when operating their own OHTTP gateways.First: We wanted to abstract away as much of the complexity of OHTTP as possible for your app servers. We wanted developers to be able to start receiving OHTTP while continuing to accept regular HTTP traffic if they chose. So, we designed the Gateway as a feature of your\u00a0zone, where clients send well-formatted\u00a0OHTTP requests to a /.well-known/ohttp-gateway\u00a0endpoint on your zone. We support both standard and chunked OHTTP\u00a0\u2014 and we recommend using chunked OHTTP for better performance, because it enables us to process requests incrementally (in \u201cchunks\u201d).Our Gateway service will intercept each request, decrypt it, issue a subrequest to your app server, and return an encrypted response to the client. All non-OHTTP requests will travel to your server without invoking the Gateway.Binding your Gateway to your zone also enables us to protect your Gateway from abuse. A client sending requests to your zone `example.com` may send to `foo.example.com` or `bar.example.com`, but not wikipedia.com. Without you needing to worry about it, this prevents unauthorized clients from using your zone as a way to target other domains.Second: Seamless key management is critical.\u00a0Gateways need to maintain a public HPKE key configuration to enable clients to encrypt requests, but managing keys securely is a challenge. So, we designed the Gateway to fully manage all keys for customers, and to serve public keys as responses to GET requests to \u00a0/.well-known/ohttp-gateway. For stronger privacy, clients can download keys over a different IP than they request the gateway.Third: Gateways need to be able to authenticate relays. Because the Gateway (by design) knows very little about the client sending a given request, it places trust in the relay to authenticate clients and forward traffic responsibly. But how do you ensure that only trusted relays can send traffic to your gateway?We designed the Gateway such that\u00a0Cloudflare Access, Cloudflare\u2019s zero trust network access product, runs before requests are decrypted, enabling you to use any standard Access policies\u00a0to authenticate incoming traffic and protect your Gateway from abuse. Options include mutual TLS, static service credentials, and custom external logic.Finally: Mistakes happen, and we anticipated that customers might accidentally break OHTTP\u2019s privacy model by running both their relay and gateway on Cloudflare. So, to preserve OHTTP\u2019s separation of trust and ensure that Cloudflare never sees both client identities and decrypted inner requests, our Gateway will refuse\u00a0to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare.When is the OHTTP Gateway a better fit than the OHTTP Relay?If you want to use Cloudflare\u2019s OHTTP product suite, but you\u2019re wondering why you\u2019d pick Cloudflare\u2019s OHTTP Gateway instead of the OHTTP Relay, here are a couple of considerations.First, do you want your app servers on Cloudflare \u2013 behind our CDN or built on Workers, for example? If so, the OHTTP Gateway is a better fit to ensure adherence to OHTTP\u2019s privacy model.Second, what\u2019s your use case? If you want to receive OHTTP requests from a third-party client and relay \u2014 to use\u00a0Apple\u2019s LiveCallerID\u00a0SDK, for example \u2014 then the OHTTP Gateway is likely the better solution for you. \u00a0Getting startedIf you have a feature request or would like to register for our waitlist, so we can notify you when the product launches, sign up here.Then, you\u2019ll need to implement an OHTTP client. See ohttp.info\u00a0or our sample client library\u00a0for some examples to help you get started. One flag as you build the client: OHTTP provides privacy at the network level, and doesn\u2019t touch the inner request body. So, to preserve user privacy, it\u2019s up to you not to send identifying information (e.g. a user\u2019s email address or username) in the request body.Next, you\u2019ll need to bring your own relay. Relays can run on any infrastructure provider, and they\u2019re simple: here\u2019s some sample code. The challenge and the reason you might want a dedicated OHTTP relay provider, is to verifiably promise to your users that you won\u2019t inspect logs with client identifiers. Otherwise, you\u2019d be able to correlate clients at the relay with decrypted requests at your app servers. \u00a0Finally, once your OHTTP deployment is live, check out our pvcli client\u00a0to help with testing and debugging. We\u2019re excited to bring accessible privacy infrastructure to developers everywhere. Reach out to us\u00a0if you\u2019d like to try out the new OHTTP Gateway and raise the bar for privacy online." ], "output": "readability", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:23.395750+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T16:26:38.195995+00:00", "index_texts": null, "output": "Announcing Cloudflare OHTTP Gateway \u2013 expanding access to Cloudflare\u2019s privacy-preserving infrastructure | Cloudflare Blog", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:38.084200+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T10:07:18.893385+00:00", "index_texts": null, "output": "Announcing Cloudflare OHTTP Gateway \u2013 expanding access to Cloudflare\u2019s privacy-preserving infrastructure | Cloudflare Blog", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:18.789762+00:00", "status": "succeeded" }, { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-03T19:27:23.390535+00:00", "index_texts": null, "output": "Announcing Cloudflare OHTTP Gateway \u2013 expanding access to Cloudflare\u2019s privacy-preserving infrastructure | Cloudflare Blog", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:23.269693+00:00", "status": "succeeded" } ], "wget": [ { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-03T16:26:38.078408+00:00", "index_texts": null, "output": "IndexError: list index out of range", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T16:26:37.702033+00:00", "status": "failed" }, { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-03T10:07:18.779921+00:00", "index_texts": null, "output": "blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/index.html", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T10:07:14.706582+00:00", "status": "succeeded" }, { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-03T19:27:23.263795+00:00", "index_texts": null, "output": "IndexError: list index out of range", "pwd": "/data/archive/1791021967.728559", "schema": "ArchiveResult", "start_ts": "2026-10-03T19:27:22.845416+00:00", "status": "failed" } ] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": null, "dom": null, "favicon": "favicon.ico", "git": null, "media": null, "pdf": null, "screenshot": null, "singlefile": null, "title": "Announcing Cloudflare OHTTP Gateway \u2013 expanding access to Cloudflare\u2019s privacy-preserving infrastructure | Cloudflare Blog", "warc": null, "wget": "IndexError: list index out of range" }, "link_dir": "/data/archive/1791021967.728559", "newest_archive_date": "2026-10-03T19:27:26.331051+00:00", "num_failures": 2, "num_outputs": 16, "oldest_archive_date": "2026-10-03T10:07:13.711763+00:00", "path": "/announcing-cloudflare-ohttp-gateway/", "schema": "Link", "scheme": "https", "snapshot_id": "eef7e79f-378e-48b2-820e-398ed810b862", "sources": [ "/data/sources/1791021967-import.txt" ], "tags": ",war-wiki", "tags_str": "war-wiki", "timestamp": "1791021967.728559", "title": "Announcing Cloudflare OHTTP Gateway \u2013 expanding access to Cloudflare\u2019s privacy-preserving infrastructure | Cloudflare Blog", "updated": "2026-10-03T19:27:21.608779+00:00", "updated_date": "2026-10-03 19:27", "url": "https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/" }