<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="https://www.getpagespeed.com/wp-content/plugins/seriously-simple-podcasting/templates/feed-stylesheet.xsl?v=2"?><rss version="2.0"
	 xmlns:content="http://purl.org/rss/1.0/modules/content/"
	 xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	 xmlns:dc="http://purl.org/dc/elements/1.1/"
	 xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	 xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	 xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	 xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"
	 xmlns:podcast="https://podcastindex.org/namespace/1.0"
	 xmlns:ssp="https://castos.com/seriously-simple-podcasting/namespace/1.0"
	>
		<channel>
		<title>Scalable Stories</title>
		<atom:link href="https://www.getpagespeed.com/feed/podcast/scalable-stories/" rel="self" type="application/rss+xml"/>
		<link>https://www.getpagespeed.com/podcasts/scalable-stories</link>
		<description>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</description>
		<lastBuildDate>Thu, 17 Sep 2026 04:20:35 +0000</lastBuildDate>
		<language>en-US</language>
		<copyright>© 2024 GetPageSpeed LLC</copyright>
		<itunes:subtitle>Mastering Web Performance and Security</itunes:subtitle>
		<itunes:author>GetPageSpeed</itunes:author>
		<itunes:type>episodic</itunes:type>
		<itunes:summary>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</itunes:summary>
		<itunes:owner>
			<itunes:name>GetPageSpeed</itunes:name>
		</itunes:owner>
		<itunes:explicit>false</itunes:explicit>
		<itunes:image href="https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg"></itunes:image>
			<image>
				<url>https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg</url>
				<title>Scalable Stories</title>
				<link>https://www.getpagespeed.com/podcasts/scalable-stories</link>
			</image>
		<itunes:category text="Technology">
		</itunes:category>
		<googleplay:author><![CDATA[GetPageSpeed]]></googleplay:author>
						<googleplay:description>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</googleplay:description>
			<googleplay:explicit>No</googleplay:explicit>
			<googleplay:image href="https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg"></googleplay:image>
			<podcast:locked>yes</podcast:locked>
		<podcast:funding url="https://github.com/sponsors/GetPageSpeed">Donate to the show</podcast:funding>
		<podcast:guid>77f42753-75ee-5503-9c62-e1dd03e62708</podcast:guid>
		
		<!-- podcast_generator="SSP by Castos/3.17.0" Seriously Simple Podcasting plugin for WordPress (https://wordpress.org/plugins/seriously-simple-podcasting/) -->
		<generator>https://wordpress.org/?v=7.1</generator>
<site xmlns="com-wordpress:feed-additions:1">74128791</site>
<item>
	<title>NGINX Certificate Compression: RFC 8879 for Every Browser</title>
	<link>https://www.getpagespeed.com/podcast/nginx-certificate-compression-audio</link>
	<pubDate>Tue, 15 Sep 2026 22:17:45 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=124068</guid>
	<description><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the servers first flight and competes with the initial congestion window and QUICs 3x amplification limit. RFC 8879 certificate compre]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX Certificate Compression: RFC 8879 for Every Browser]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-certificate-compression-audio.m4a" length="8222351" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:10:54</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>Post-Quantum NGINX: OpenSSL 3.5 on Debian and Ubuntu</title>
	<link>https://www.getpagespeed.com/podcast/nginx-openssl35-debian-ubuntu-audio</link>
	<pubDate>Mon, 14 Sep 2026 21:50:05 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123987</guid>
	<description><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distributions system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reach]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[Post-Quantum NGINX: OpenSSL 3.5 on Debian and Ubuntu]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-openssl35-debian-ubuntu-audio.m4a" length="7142106" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:09:27</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>OpenSSL 4.0 for NGINX: Why We Ship 3.5 LTS Instead</title>
	<link>https://www.getpagespeed.com/podcast/openssl-4-nginx-audio</link>
	<pubDate>Mon, 14 Sep 2026 02:59:02 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123912</guid>
	<description><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but i]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[OpenSSL 4.0 for NGINX: Why We Ship 3.5 LTS Instead]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/openssl-4-nginx-audio.m4a" length="7002838" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:09:16</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>zstd-nginx-module: Maintained, Tested and Packaged</title>
	<link>https://www.getpagespeed.com/podcast/zstd-nginx-module-audio</link>
	<pubDate>Sun, 13 Sep 2026 01:47:50 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123807</guid>
	<description><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that si]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[zstd-nginx-module: Maintained, Tested and Packaged]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/zstd-nginx-module-audio.m4a" length="11858429" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:15:42</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX RADIUS Authentication: No More htpasswd Files</title>
	<link>https://www.getpagespeed.com/podcast/nginx-radius-authentication-audio</link>
	<pubDate>Sat, 12 Sep 2026 02:27:41 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123718</guid>
	<description><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer t]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX RADIUS Authentication: No More htpasswd Files]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-radius-authentication-audio.m4a" length="6529510" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:08:38</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>ECH Without Padding Is a Lookup Table</title>
	<link>https://www.getpagespeed.com/podcast/ech-handshake-padding-audio</link>
	<pubDate>Fri, 11 Sep 2026 06:09:08 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123655</guid>
	<description><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the servers encrypted handshake flight (EncryptedExtensions, Ce]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[ECH Without Padding Is a Lookup Table]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/ech-handshake-padding-audio.m4a" length="8054478" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:10:39</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX TLS Vulnerability Fixes: BREACH, SWEET32, ROBOT</title>
	<link>https://www.getpagespeed.com/podcast/nginx-tls-vulnerability-fixes-audio</link>
	<pubDate>Wed, 09 Sep 2026 22:24:45 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123557</guid>
	<description><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></description>
	<itunes:subtitle><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, ]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX TLS Vulnerability Fixes: BREACH, SWEET32, ROBOT]]></itunes:title>
	<content:encoded><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-tls-vulnerability-fixes-audio.m4a" length="5606699" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:07:26</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX proxy_pass: URI Rewriting, Variables, and DNS Gotchas</title>
	<link>https://www.getpagespeed.com/podcast/nginx-proxy-pass-audio</link>
	<pubDate>Tue, 08 Sep 2026 22:41:54 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123484</guid>
	<description><![CDATA[NGINX proxypass: URI Rewriting, Variables, and DNS Gotchas — Technical Briefing Problem Statement The proxypass directive in NGINX has several non-obvious behaviors around URI rewriting, DNS resolution, and configuration placement. Misunderstanding these behaviors leads to common production failures: double slashes in paths, concatenated URIs, HTTP 502 errors after backend IP rotation, and configuration load failures. The root causes are threefold: NGINX rewrites URIs only under specific syntac…]]></description>
	<itunes:subtitle><![CDATA[NGINX proxypass: URI Rewriting, Variables, and DNS Gotchas — Technical Briefing Problem Statement The proxypass directive in NGINX has several non-obvious behaviors around URI rewriting, DNS resolution, and configuration placement. Misunderstanding these]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX proxy_pass: URI Rewriting, Variables, and DNS Gotchas]]></itunes:title>
	<content:encoded><![CDATA[NGINX proxypass: URI Rewriting, Variables, and DNS Gotchas — Technical Briefing Problem Statement The proxypass directive in NGINX has several non-obvious behaviors around URI rewriting, DNS resolution, and configuration placement. Misunderstanding these behaviors leads to common production failures: double slashes in paths, concatenated URIs, HTTP 502 errors after backend IP rotation, and configuration load failures. The root causes are threefold: NGINX rewrites URIs only under specific syntac…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-proxy-pass-audio.m4a" length="5920654" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[NGINX proxypass: URI Rewriting, Variables, and DNS Gotchas — Technical Briefing Problem Statement The proxypass directive in NGINX has several non-obvious behaviors around URI rewriting, DNS resolution, and configuration placement. Misunderstanding these behaviors leads to common production failures: double slashes in paths, concatenated URIs, HTTP 502 errors after backend IP rotation, and configuration load failures. The root causes are threefold: NGINX rewrites URIs only under specific syntac…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:07:50</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[NGINX proxypass: URI Rewriting, Variables, and DNS Gotchas — Technical Briefing Problem Statement The proxypass directive in NGINX has several non-obvious behaviors around URI rewriting, DNS resolution, and configuration placement. Misunderstanding these behaviors leads to common production failures: double slashes in paths, concatenated URIs, HTTP 502 errors after backend IP rotation, and configuration load failures. The root causes are threefold: NGINX rewrites URIs only under specific syntac…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX Directive Execution Order: The 11 Request Phases</title>
	<link>https://www.getpagespeed.com/podcast/nginx-directive-execution-order-audio</link>
	<pubDate>Mon, 07 Sep 2026 22:33:00 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123409</guid>
	<description><![CDATA[NGINX Directive Execution Order: The 11 Request Phases Problem Statement NGINX processes every request through a fixed pipeline of eleven phases. A directive does not run where it is written in the configuration file—it runs when its phase comes up in the pipeline. This explains common configuration "bugs" that are not actually bugs but rather misunderstandings of phase ordering. When a configuration behaves unexpectedly, reading the file top to bottom is the wrong approach; the correct questio…]]></description>
	<itunes:subtitle><![CDATA[NGINX Directive Execution Order: The 11 Request Phases Problem Statement NGINX processes every request through a fixed pipeline of eleven phases. A directive does not run where it is written in the configuration file—it runs when its phase comes up in th]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX Directive Execution Order: The 11 Request Phases]]></itunes:title>
	<content:encoded><![CDATA[NGINX Directive Execution Order: The 11 Request Phases Problem Statement NGINX processes every request through a fixed pipeline of eleven phases. A directive does not run where it is written in the configuration file—it runs when its phase comes up in the pipeline. This explains common configuration "bugs" that are not actually bugs but rather misunderstandings of phase ordering. When a configuration behaves unexpectedly, reading the file top to bottom is the wrong approach; the correct questio…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-directive-execution-order-audio.m4a" length="5886573" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[NGINX Directive Execution Order: The 11 Request Phases Problem Statement NGINX processes every request through a fixed pipeline of eleven phases. A directive does not run where it is written in the configuration file—it runs when its phase comes up in the pipeline. This explains common configuration "bugs" that are not actually bugs but rather misunderstandings of phase ordering. When a configuration behaves unexpectedly, reading the file top to bottom is the wrong approach; the correct questio…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:07:48</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[NGINX Directive Execution Order: The 11 Request Phases Problem Statement NGINX processes every request through a fixed pipeline of eleven phases. A directive does not run where it is written in the configuration file—it runs when its phase comes up in the pipeline. This explains common configuration "bugs" that are not actually bugs but rather misunderstandings of phase ordering. When a configuration behaves unexpectedly, reading the file top to bottom is the wrong approach; the correct questio…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX Early Hints: HTTP 103 Benchmarked on Enterprise Linux</title>
	<link>https://www.getpagespeed.com/podcast/nginx-early-hints-audio</link>
	<pubDate>Sun, 23 Aug 2026 20:42:03 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=122391</guid>
	<description><![CDATA[Technical Briefing: NGINX Early Hints (HTTP 103) on Enterprise Linux Problem Statement HTTP Early Hints (status code 103) allows a server to send preliminary response headers—such as Link headers for render-blocking resources—before the final response, enabling browsers to begin fetching critical assets while the origin is still generating the HTML. This can significantly reduce Largest Contentful Paint (LCP) when the origin has real server-side think-time. However, the earlyhints directive, av…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: NGINX Early Hints (HTTP 103) on Enterprise Linux Problem Statement HTTP Early Hints (status code 103) allows a server to send preliminary response headers—such as Link headers for render-blocking resources—before the final response, e]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX Early Hints: HTTP 103 Benchmarked on Enterprise Linux]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: NGINX Early Hints (HTTP 103) on Enterprise Linux Problem Statement HTTP Early Hints (status code 103) allows a server to send preliminary response headers—such as Link headers for render-blocking resources—before the final response, enabling browsers to begin fetching critical assets while the origin is still generating the HTML. This can significantly reduce Largest Contentful Paint (LCP) when the origin has real server-side think-time. However, the earlyhints directive, av…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/08/nginx-early-hints-audio.m4a" length="5640083" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: NGINX Early Hints (HTTP 103) on Enterprise Linux Problem Statement HTTP Early Hints (status code 103) allows a server to send preliminary response headers—such as Link headers for render-blocking resources—before the final response, enabling browsers to begin fetching critical assets while the origin is still generating the HTML. This can significantly reduce Largest Contentful Paint (LCP) when the origin has real server-side think-time. However, the earlyhints directive, av…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:07:27</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: NGINX Early Hints (HTTP 103) on Enterprise Linux Problem Statement HTTP Early Hints (status code 103) allows a server to send preliminary response headers—such as Link headers for render-blocking resources—before the final response, enabling browsers to begin fetching critical assets while the origin is still generating the HTML. This can significantly reduce Largest Contentful Paint (LCP) when the origin has real server-side think-time. However, the earlyhints directive, av…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>
	</channel>
</rss>
