HTTP Reviews

Traefik Reviews

HTTP mentions (9)

• The History of HTTP

  HTTP/1.1 was first published as RFC 2068 (The Proposed Standard) in January 1997. HTTP/1.1 protocol was refined over two revisions, RFC 2616 published in June 1999 and RFC 7230-RFC 7235 published in June 2014 before the release of HTTP/2. The HTTP/1.1 standard (RFC 2616) remained stable for over 15 years. In 2022, HTTP/1.1 was updated again with RFC 9110 & RFC 9112. - Source: dev.to / 9 months ago

• State management in Svelte apps

  HTTP was invented as a stateless protocol, which means that each request fully encapsulates all of the information necessary to return a correct response. So historically, web pages never had to worry about managing state - each request to a URL with parameters or with a form submission would receive a response with all of the HTML that the browser needed to render content. - Source: dev.to / about 2 years ago

• Evolving the Web: Discovering the History of HTTP Versions

  HTTP/1.1 was such a game changer for the Internet that it works so well that even through two revisions, RFC 2616 published in June 1999 and RFC 7230– RFC 7235 published in June 2014, HTTP/1.1 was extremely stable until the release of HTTP/2.0 in 2014 — Nearly 18 years later. Before continuing to the next section about HTTP/2.0, let us revisit what journey HTTP/1.1 has been through. - Source: dev.to / almost 3 years ago

• Poll: Are client web requests sent to upstream servers or downstream servers?

  On the one hand, it just seems natural that "upstream" refers to the inbound request being sent from one system to another. It takes effort (connection pooling, throttling, retries, etc.) to make a request to an (upstream) dependency, just as it takes effort to swim upstream. The response is (usually) easy... Just return it... hence, "downstream". Recall the usual meaning of "upload" and "download". Upstream seems... - Source: Hacker News / over 4 years ago

• How to cache TCP, SSL handshake on ALB?

  To me it sounds like you’ve not solved this as the config you’ve mentioned is about preventing “illegal” (none RFC7230 ) requests, it isn’t really related to the problem you posted. Source: over 4 years ago

Traefik mentions (43)

• My homelab stack in 2026: what runs, why, and how it all connects

  Everything HTTP goes through Traefik. It's the reverse proxy in front of every Docker-hosted service, and the main reason I chose it over Nginx or Caddy is Docker-native autodiscovery. When I bring up a new container with the right labels, it appears behind a subdomain with automatic TLS, no config file reload required. That removes enough friction that I'm less tempted to leave things running unproxied on bare... - Source: dev.to / about 1 month ago

• Traefik vs HAProxy: Reverse Proxy Showdown

  Traefik (v3.6) is a cloud-native edge router that watches Docker, Kubernetes, and other providers for service changes. When you deploy a new container with the right labels, Traefik automatically creates a route and provisions an SSL certificate. Configuration is split between a static config file (entry points, providers) and dynamic config (Docker labels on each service). - Source: dev.to / 4 months ago

• Traefik vs Caddy: Which Reverse Proxy?

  Traefik (v3.6) is a cloud-native edge router written in Go. It watches Docker, Kubernetes, and other providers for service changes and automatically creates routes based on labels. Configuration is split between a static config file and dynamic config via labels or files. Traefik has been around since 2016 and is widely used in production orchestration environments. - Source: dev.to / 4 months ago

• Controlling Kubernetes Network Traffic – Part 1

  Traefik is a modern, cloud-native reverse proxy and load balancer that also serves as a Kubernetes Ingress Controller. It acts as an in-cluster application that integrates with the Kubernetes API to automatically detect Ingress resources and dynamically configure itself to route incoming HTTP/HTTPS traffic to the appropriate backend services within the cluster. - Source: dev.to / 8 months ago

• Why We Moved API Authentication from the Gateway to Our Microservices

  Then we started looking into Kong alternatives, and found multiple options: Envoy, Traefik, etc... But migrating from Kong plugin into those would be a bit painful and wasn't guaranteed to be smooth as we use a single domain and it can point to only one of those Ingress controllers. - Source: dev.to / 9 months ago