NaiveProxy URI Specification

naiveproxy-uri-specs.md

Basic

• NaiveProxy URIs should be standard URIs, not something using JSON and Base64 encoding, etc.
• https / quic schemes shouldn't be used directly, since they can be confusing with the real protocols.

Rules

• schema := naive+https | naive+quic
• username, password := basic auth info. when there's no auth, omit both.
• host := target host
• port can be omitted if it's 443, or specify it explicitly
• queries:
  • padding := 'true' | 'false' - whether to use padding or not. when omitted, use 'false' as default.
  • extra-headers := encodeURIComponent((HEADER ':' VALUE)?( '\0d\0a' HEADER ':' VALUE)*) - extra headers to add, where:
    • HEADER is a random combination of !#$%&'*+-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ\\^_`abcdefghijklmnopqrstuvwxyz|~;
    • VALUE is a random string without \0d, \0a and \00.
• fragment: used to place descriptive texts

Examples

• naive+https://what:[email protected]?padding=false#Naive!
• naive+https://some.public.rs?padding=true#Public-01
• naive+quic://manhole:[email protected]
• naive+https://some.what?extra-headers=X-Username%3Auser%0D%0AX-Password%3Apassword

Application

Launchers simply strip naive+ from the scheme part, strip and parse the url queries for extra arguments, and strip fragment as optional descriptive text. Afterwards, he/she can directly pass this stripped uri following --proxy= in NaiveProxy argument list. After adding extra arguments like --padding and --extra-headers, NaiveProxy is ready to go.

This URI can also be used in subscriptions, when mixed with other protocols, this scheme is easily distinguishable since we have a prefix naive+. This allows further parsing of the subscribed hosts.