Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html 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. * "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. * Proxy-Authorization Don't we need to continue to support http clients where we can't specify custom headers? 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. * 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. * "X-Tor-Family-Preference: IP version preferences" What is this for? Is there not an existing way to control this over HTTP? * "X-Tor-Proxy: Indication for Tor proxy protocol support" Why does this need to be separate from the X-Tor-Capabilities ? * 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.) Thanks for your attention, Ian.