Sorry for the delay replying: Nick Mathewson writes ("Re: [tor-dev] Proposal 365, review notes"):
On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev
* "X-Tor-RPC-Target: Arti RPC support" is weird.
Firstly, is this being a protocol registry?
Secondly, do we not have a notion of critical extensions? We should be using that for something like this.
What is the "this" that you're asking about in the sense of being a protocol registry, and how would it be a protocol registry? Do you mean, are we starting a list of special Tor HTTP CONNECT extensions? If so, we already have such a list in https://spec.torproject.org/http-connect.html . But I think you must mean something else?
I think I must have misread it somehow. My previous comment now makes no sense to my current self. Sorry!
As for critical extensions: I don't think HTTP does those? Even if we add a specific "critical extension" mechanism to our own headers, we can't rely on any other implementation rejecting requests that have them.
In that case, this text in the proposal Implementations that do not support Arti RPC should reject requests containing this header. is doubtful. It might be an attempt to modify the base HTTP protocol and make an incompatible version of it. Maybe we could say something like An HTTP proxy that knows that it is forwarding requests over Tor, and generally supports these Tor extensions, should reject requests with this header, if it doesn't support Arti RPC. ?
If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation.
The idea here is that the existing mechanism (using the whole proxy-authorization content) would work, but it would be deprecated and cause a warning when used, whereas the new scheme (using Basic with username x-tor) would be the non-deprecated thing. I'll add a note about deprecation.
But:
Don't we need to continue to support http clients where we can't specify custom headers?
I think so, yes.
I don't think we ought to try to deprecate clients were we can't specify custom headers. This implies that there should be a non-deprecated way to pass stream isolation information to a Tor HTTP proxy. That non-deprecated way ought not to use the bad "whole value" approach. IOW the present proposal deprecates the bad thing, but it doesn't provide a practical replacement.
* "X-Tor-Family-Preference: IP version preferences"
What is this for? Is there not an existing way to control this over HTTP?
I cannot find any such header for regular HTTP.
Hrm. I looked in MDN too, and didn't find one. There's Prefer but I don't think that's addressed strictly to proxies, and we'd have to have an ad-hoc extension there. It's probably better to invent our own header.
* "X-Tor-Proxy: Indication for Tor proxy protocol support"
Why does this need to be separate from the X-Tor-Capabilities ?
The idea is that this tells you what the proxy implementation is, and that you'd use it for bug-checking as noted below.
I think the comment field in the HTTP `Via` header could be used for this? I would very much prefer to direct people to a formal capabilities header. Certainly, testing for whether this is a Tor proxy ought to be done with the capabilities header.
* Capabilities
Clients SHOULD NOT inspect the contents of this header to determine whether a given feature is supported or not.
Should be MUST NOT. Capability guessing via version strings is completely terrible.
I suggest:
Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used.
(This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.)
Agreed.
While I was looking at this I found the Accept-CH header. I think we don't want to use it here, but I thought I'd mention it. Also, since I was browsing MDN: Should we do something intelligent with Vary? Ian.