On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev <[email protected]> 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_3236424 > > 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 _______________________________________________ tor-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
