[Masque] Re: Fwd: Request for Assignment (http-proxy-status)

[Ben Schwartz <[e-mail]>]

If the purpose of the registration is only to prevent colliding uses of this string, and not to promote interoperable uses of it, then the registry entry should be marked "reserved" with some explanatory text.

--Ben Schwartz
________________________________
From: Lucas Pardue <[e-mail]>
Sent: Thursday, September 25, 2025 10:09 PM
To: David Schinazi <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Masque] Re: Fwd: Request for Assignment (http-proxy-status)

On Fri, Sep 26, 2025, at 02: 34, David Schinazi wrote: If we were designing this greenfield, then I'd agree with you. It's more that this is in production, and I suggested to folks that they register it to avoid conflicts. I appreciate the constraints



On Fri, Sep 26, 2025, at 02:34, David Schinazi wrote:
If we were designing this greenfield, then I'd agree with you. It's more that this is in production, and I suggested to folks that they register it to avoid conflicts.

I appreciate the constraints at play and ultimately it's going to be up to the expert to make the call.

However, this would seem to be the first case of registering something with no spec and no wiggle room on its naming. Unfortunately, based on RFC 9209's guidance [1],  that tends me to think it's not something that should be registered, lest we risk confusing people that want to use the proxy-status field and might misuse this error type. The name conflict risks seem minimal, especially given the deployment models. All that said, if I'm in the rough and the expert approves the request I could live with the outcome.

[1] https://www.rfc-editor.org/rfc/rfc9209.html#register-error<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9209.html*register-error__;Iw!!Bt8RZUm9aw!89fseinCcWfLhpubKMSw2Dz-S8lgIwvxPCkKOC1Q-j0DH9iucbryTY6Z1qajZFpJkoyNDimBV43K$>

David

On Thu, Sep 25, 2025 at 6:30 PM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:

Thanks for the additional info David.

On Fri, Sep 26, 2025, at 01:55, David Schinazi wrote:
We're using this in production to have one of our IP Protection ProxyB providers (not the one you work for) tell Chrome that it's not allowed to CONNECT/connect-udp this domain. You could conceivably use http_request_denied for this (which is what our other ProxyB provider is doing) but it's less specific, so specifying a new one makes sense.

I'm still struggling to understand why it helps. http_request_denied is defined as

> The intermediary rejected the HTTP request based on its configuration and/or policy settings.

And the ACL matter seems completely in scope of policy setting. The registration request doesn't include any extra parameters that might motivate using this new type in preference of the existing one. If it did, that might be a stronger selling point.

I might guess the client can do something with origin_acl that it can't do with the generic one? But is that broadly applicable?

I'm wondering if the request proposal would be stronger by making it more generic as just "acl" with some parameters that can specific if it is a client or a destination ACL rule that triggered the fail. Appreciate that would be more work for you though.


I agree with you that calling this "origin" isn't a fully correct use of the HTTP terminology, perhaps "target" would have been clearer. But this is HTTP, and our terminology is fun :-)
Alternatively to thr "acl" suggestion above, if the error type is solely related to policy choice based on the destination details, perhaps just "destination_prohibited" would be in keeping with existing values and good enough? I imagine a CONNECT(-UDP) proxy would do the check before with some policy/config would even bothering with IP resolution.

Cheers
Lucas

David

On Thu, Sep 25, 2025 at 5:16 PM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

Since I'm not sure where this request came from, I'm somewhat speaking into the ether but here goes.

Without some more substantial documentation I don't understand the usecase. The Proxy Error Types Registry already has "destination_ip_prohibited", "connection_refused" or "http_request_denied" that all seem like they might be reasonable to use in the case where a forward proxy is rejecting a request. There's no definition of ACL for this regeistrstion request, so it seems a bit vague. Adding "origin" in the terms seems to make the whole thing even more confusing.

Cheers
Lucas

On Fri, Sep 26, 2025, at 00:53, Mark Nottingham wrote:
Hi everyone,

With my HTTP Proxy Error Types Expert hat on, we've received the following request, and per the RFC I'm asking for any community feedback.

Thoughts?

Cheers,


Begin forwarded message:


Type of Assignment:
Name: origin_acl
Description: The intermediary rejected the HTTP request based on ACL rules which prohibit access to the requested next hop.
Extra Parameters: None
Recommended HTTP Status Code: 403
Response Only Generated by Intermediaries: true

Registry:
https://www.iana.org/assignments/http-proxy-status/http-proxy-status.xhtml#http-proxy-error-types<https://urldefense.com/v3/__https://www.iana.org/assignments/http-proxy-status/http-proxy-status.xhtml*http-proxy-error-types__;Iw!!Bt8RZUm9aw!89fseinCcWfLhpubKMSw2Dz-S8lgIwvxPCkKOC1Q-j0DH9iucbryTY6Z1qajZFpJkoyNDvhMLzgK$>

Description:
We're running a MASQUE/CONNECT/ProxyB server for (multi party) private relay style architectures and would like to signal to clients that a proxy attempt was rejected due to origin ACL rules.

Additional Info:
https://www.rfc-editor.org/rfc/rfc9209.html#name-proxy-error-types<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9209.html*name-proxy-error-types__;Iw!!Bt8RZUm9aw!89fseinCcWfLhpubKMSw2Dz-S8lgIwvxPCkKOC1Q-j0DH9iucbryTY6Z1qajZFpJkoyNDnDU2YEW$>

--
Mark Nottingham   https://www.mnot.net/<https://urldefense.com/v3/__https://www.mnot.net/__;!!Bt8RZUm9aw!89fseinCcWfLhpubKMSw2Dz-S8lgIwvxPCkKOC1Q-j0DH9iucbryTY6Z1qajZFpJkoyNDiWZtXgd$>
--
Masque mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
Masque mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>