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.
_______________________________________________
tor-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
