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

Hey,

On Wed, Feb 11, 2026, at 23:29, Kazuho Oku wrote:
> 2026年2月11日(水) 9:02 Lucas Pardue <lucas@lucaspardue.com>:L
> 
> >g
> > 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.

Ah, this is starting to bring back some memories for a few years ago. Thanks!

If I recall correctly, there's been a bit of reluctance to get into the aspects of PAC contents, parsing etc. That seems fine and sensible. But I do wonder if this doc could benefit from trying to capture some of the practice or guidance about HTTP transfer aspects to help implementers treat the new proposed minimal signal in a way that can succeed.

Cheers
Lucas