Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #15035

Closed
Open
Opened Feb 25, 2015 by eighthave@eighthave

URI format for bridges

Right now, according to @n8fr8, this is the URI format for the bridge URIs:

bridge://obfs3+99.999.99.999%3A10223+c6fa110ebcd8979b0a57617bf2d6e82bbecd287d+%0A

There is a problem with this format because it doesn't follow the URI RFC so that standard URI parsers won't parse it very well. Adding the // after bridge: makes it a "hierarchical" URI, which means that it has the standard sections of authority, user info, host, port, path, query, and fragment. But the above URI will just stick all of the text in the "authority" part, but that section can't be broken down into the standard parts of the "authority", i.e. user info, host, and port.

To keep the same data format, then this URI should be an "opaque" URI. That just means removing the //. So that makes it like a mailto: URI.

Otherwise, the data could be refactored to fit into the standard parts for a hierarchical URI, then standard URI parsing classes will be able to parse it. For example, android.net.Uri, java.net.URL, etc. That would make the URI look something like this:

obfs4://xx.xx.xxx.xxx:18965/asdasdasldkasjlasjkdd4?cert=3wYasdasdasdasBmsIat+RMmMDV5BV4jDvXuzasdasdasdas8Dz8J1MUvLKHKaQ&iat-mode=0

  • getScheme() would be bridge type
  • getAuthority() would be IP and port number
  • getHost() would be IP
  • getPort() would be port number
  • getPath() would be this thing: 95151988dc29fccb4f610a1c700a1ddf7d5ffbd4
  • then cert=, iat-mode=, etc. would be in the query string

The downside of this approach is that there could only be a single bridge per URI, but maybe that's not so bad.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#15035