- From: Tommy Pauly <tpauly@apple.com>
- Date: Sat, 05 Jul 2025 12:45:29 -0700
- To: Yaroslav Rosomakho <yrosomakho@zscaler.com>
- Cc: ietf-http-wg@w3.org
- Message-id: <ACC3474F-D3D2-4DB2-877A-D69320E8D0FB@apple.com>
Thanks for sharing this here, Yaroslav. As a bit of background on this, this is a topic that came up in discussions around a document we have in INTAREA that’s nearing completion (https://www.ietf.org/archive/id/draft-ietf-intarea-proxy-config-06.html) that provides one mechanism for advertising proxy configurations. However, this problem of learning that a proxy config seems out of date and should be refreshed is not unique to that — it applies to PAC and to other bespoke proxy configuration approaches. I do think this is a real problem, and something worth solving with a mechanism that is similar to the one proposed in the draft. I’ve seen the need for this kind of signal in privacy proxy configurations, and we’ve used some proprietary headers or interpretations of status codes to trigger configuration re-fetches there. Having a standard way would make this more useful. Best, Tommy (as an individual only) > On Jun 29, 2025, at 3:58 PM, Yaroslav Rosomakho <yrosomakho@zscaler.com> wrote: > > Dear HTTP enthusiasts, > > Clients relying on explicit HTTP proxies often need to frequently query proxy configuration files (PAC files today, PvD-based proxy configurations in the future) to detect updates. This can lead to unnecessary polling, increased network load, and delayed application of critical changes. > > To address this, I’ve published a simple draft that defines a mechanism for proxies to inform clients when their configuration appears outdated. The draft introduces two new HTTP headers: > - Proxy-Config: included in client requests to indicate the URL and timestamp of the current proxy configuration. > - Proxy-Config-Stale: an optional response header used by the proxy to signal whether the client’s configuration is outdated. > > This mechanism is compatible with any HTTP and MASQUE proxying including CONNECT, CONNECT-UDP, CONNECT-IP, and templated CONNECT-TCP. It's designed to be lightweight, advisory, and backward-compatible. > > Feedback and suggestions are very welcome. > > Best Regards, > Yaroslav > > ---------- Forwarded message --------- > A new version of Internet-Draft > draft-rosomakho-httpbis-outdated-proxy-config-00.txt has been successfully > submitted by Yaroslav Rosomakho and posted to the > IETF repository. > > Name: draft-rosomakho-httpbis-outdated-proxy-config > Revision: 00 > Title: Detecting Outdated Proxy Configuration > Date: 2025-06-29 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/archive/id/draft-rosomakho-httpbis-outdated-proxy-config-00.txt > Status: https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-outdated-proxy-config/ > HTML: https://www.ietf.org/archive/id/draft-rosomakho-httpbis-outdated-proxy-config-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-outdated-proxy-config > > > Abstract: > > This document defines a lightweight mechanism that allows explicit > HTTP proxies to inform clients when their proxy configuration, such > as a Proxy Auto-Configuration (PAC) file or Provisioning Domain (PvD) > proxy configuration, is outdated. Clients signal to the proxy the > configuration URL and the timestamp of when it was last fetched. In > response, the proxy may indicate that a newer version of the > configuration is available. This enables clients to refresh their > configuration without relying on frequent polling or short expiration > intervals. The mechanism is designed to be compatible with existing > proxy deployment models and supports both PAC-based and PvD-based > configurations. > > > > The IETF Secretariat > > > > > This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
Received on Saturday, 5 July 2025 19:45:45 UTC