On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev <tor-dev@lists.torproject.org> wrote:
Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html
Hi, thanks for the tenses!
I hate these notes:
* Tenses are weird.
The whole proposal is written in a weird mix of tenses and sometimes in a weird mood. Writing the specifications in the future tense is confusing and will make moving the text to the main spec (which we should do after approval and as part of implementation) much harder.
There should not be statements like "we should". Specifications, even proposals, should be definitive and therefore should be definite.
So everything should be written in the present imperative.
I'll try to do this in a revision.
* "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? 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. We _could_ say that some extensions are "critical" from a Tor POV, in the sense that they mean "you must either implement this or reject it if you are a Tor implementation". Is that what you have in mind? I don't think I'm understanding your questions very well here; maybe we should meet once you're back.
* Proxy-Authorization
Don't we need to continue to support http clients where we can't specify custom headers?
I think so, yes.
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.
* Optimistic data
This has a framing hazard, which could be a vulnerability in some circumstances. I wrote about this in this torspec MR https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_323...
AFAICT that means if that MR merges, this feature will be removed? That would resolve the concern.
Yes; I'm just waiting for some of your replies on that ticket.
* "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.
* "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.
* 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. ==== Please let me know what you think about the places above; I'll start revisions on this once I know what you think. -- Nick