Re: Request for Assignment (http-proxy-status)

Hi Max (et al),

I'm not subscribed to the MASQUE list any more, so continuing the discussion over here.

It seems that this term is being used in production, however, AFAICT it's a pairwise agreement between two parties, not something that needs to be broadly interoperable. 

What you seem to want is a way to denote that the policy behind denying the request came from the origin -- even though the policy is being _applied_ at the proxy.

If that's the case, I suspect the best, spec-compliant way to do that is to use http_request_denied or similar (as others have suggested, with a detail parameter, e.g.,:

Proxy-Status: proxy.example.net; error=http_request_denied; details="origin policy violation"

Alternatively (or perhaps concurrently), it might be interesting to define a new "error_source" parameter that disambiguates where the policy came from; e.g.,

Proxy-Status: proxy.example.net; error=http_request_denied; error_source=origin

... because while not all error types have variation in source, it appears enough do to make it potentially valuable to convey, and would avoid an explosion in error types.

Does that make sense?

Regarding this request, it looks like this is already in production, albeit as a pairwise agreement between two parties, rather than something that's expected to be broadly interoperable. My initial read is that it doesn't make sense to register it, since that might confuse people about its nature (note that there is no field for 'reserved' or 'deprecated' in the registry), and the likelihood of collision is low (or at least the likelihood that registration would help avoid collision is low...).

Tell me what you think.

Cheers,



> On 7 Oct 2025, at 6:08 am, Max Bittman <max.bittman@fastly.com> wrote:
> 
> Sorry about the double posting, I hadn't been subscribed to the list previously and it didn't seem as though messages were going through.
> 
> It looks like this conversation migrated to the masque list which at this point has deeper context/background: https://mailarchive.ietf.org/arch/msg/masque/e2FU_95lbC_TCVa9hMx7BCRoOBA/
> 
> I think it's probably better that the conversation continues there.
> 
> On Fri, Oct 3, 2025 at 5:38 PM Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 03/10/2025 05:05, Max Bittman wrote:
> > 
> > I'd be happy to elaborate more on our specific use case,
> 
> 
> That might help. Yes please.
> 
> So far it seems to be a duplicate of RFC 9209 section 2.3.17:
> 
> "
> Name:    http_request_denied
> 
> Description:
>      The intermediary rejected the HTTP request based on its 
> configuration and/or policy settings. The request wasn't forwarded to 
> the next hop.
> 
> Recommended HTTP Status Code: 403
> "
> 
> 
> Cheers
> Amos
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 16 October 2025 22:05:20 UTC