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

2026年2月11日(水) 9:02 Lucas Pardue <lucas@lucaspardue.com>:
>
> 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.
>
> 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?
>
> 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).

Yeah, the PAC file is an HTTP resource, and there are existing ways in
HTTP to convey when HTTP resources have to be revalidated. Therefore,
if the clients want to proactively revalidate their PAC file, I think
those clients can rely on that.

To paraphrase, I think it makes sense for the proposed extension to
concentrate on the topic of detecting changes when the client *uses*
the configuration provided by the PAC file.

>
> === 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
>
>
>


-- 
Kazuho Oku

Received on Wednesday, 11 February 2026 23:29:30 UTC