Re: Call for adoption: draft-rosomakho-httpbis-outdated-proxy-config-01 (Ends 2026-02-03)

Thank you for your comments, Lucas.

Responses inline.

-yaroslav

On Tue, Feb 10, 2026 at 3:59 PM Lucas Pardue <lucas@lucaspardue.com> wrote:

> Hiya,
>
> Disclaimer: I typed out an email draft a few weeks ago, and paused to
> re-evaluate what I was saying. But then I ran out of time to complete it.
> I'd rather share some half-baked thoughts than share nothing. But take them
> as that.
>
> Generally speaking this seems fine to adopt. However, I'm struggling a
> little with the problem statement and how this mechanism specifically
> addresses it. This could just be my lack of understanding.
>
> IIUC the idea is to add these headers so they piggyback on CONNECT
> requests. In a situation where a configuration is stale, would a proxy
> accept or reject the request? I suspect that might be an
> implementer/operator choice.
>

Stale configuration on its own is not necessarily the reason to reject the
request. As described in section 5 of the draft the proxy may supply the
header with both successful and error responses with exception of
authentication failures.

Proxy-Config-Stale hint with successful response processes the request as
long as it is within the configured proxy policy but informs the client
that it should update the configuration to avoid potential issues in the
future. Proxy-Config-Stale with error response informs the client that it
should refresh the configuration and retry the request according to the new
settings.

If a client gets added latency from relying solely on this mechanism to try
> a request and only then find out things were stale, that doesn't sound too
> great and might leave clients still doing eager polling.
>

> Are there situations where proxy configuration changes are scheduled? In
> other words, is there a place for allowing a server to signal when a config
> might be changed? Or perhaps it would be useful for clients to know roughly
> when the thing went stale?
>
>
Traditional HTTP mechanisms such as Expires and Cache-Control that provide
caching hints to the client are not going away and should still be used. In
addition to that, PvD has its own "expires" field.

Finally, the client should still rely on its own policy that may require
more frequent configuration fetches.


> If you tweaked the response header design a bit to also be a dictionary,
> you could perhaps have a system that would allow information sharing to
> allow client implementations to develop smarter strategies. For example:
> Proxy-Config-Resp: fresh=?0, updated=(some date).
>

As mentioned above, native HTTP mechanisms already exist when proxy
configuration is fetched via a PAC file or PvD proxy configuration.


>
> === Old email end ===
>
> I'm sure there'd be issues with exposing some information and the proxy.
> That might be argument for the minimal design. The document should aim to
> capture some of that if it doesn't already - I've paged out my context so
> can't recall sorry.
>
> Cheers
> Lucas
>
> On Tue, Jan 20, 2026, at 23:48, Mark Nottingham via Datatracker wrote:
>
> This message starts a httpbis WG Call for Adoption of:
> draft-rosomakho-httpbis-outdated-proxy-config-01
>
> This Working Group Call for Adoption ends on 2026-02-03
>
> 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.
>
> Please reply to this message and indicate whether or not you support
> adoption
> of this Internet-Draft by the httpbis WG. Comments to explain your
> preference
> are greatly appreciated. Please reply to all recipients of this message and
> include this message in your response.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
> Appropriate IPR disclosures required for full conformance with the
> provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-outdated-proxy-config/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-rosomakho-httpbis-outdated-proxy-config-01.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-rosomakho-httpbis-outdated-proxy-config-01
>
>
>
>

-- 


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.