Skip to content

Bug: Tag-Only Protocols Accept Extra Value via = and Give Poor Error for /tag/value #98

@yashksaini-coder

Description

@yashksaini-coder

Tag-only protocols in multiaddr (such as /webrtc, /webrtc-direct, /noise, /quic, /http, etc) are protocols that should not be followed by any argument or value. For example, /webrtc is valid, but /webrtc/value or /webrtc=foo should be rejected.

Currently, there are two bugs affecting tag-only protocol parsing:

1. Incorrect Error Message for /tag/value Form

When parsing an address like /webrtc/value or /webrtc-direct/value, the result is rejected, but the error message is misleading:

Error: Invalid MultiAddr '/webrtc-direct/value': unknown protocol: value (string: /webrtc-direct/value)

Expected error:

Protocol 'webrtc-direct' does not take an argument

This results in confusion for users: it makes it look like "value" is an unknown protocol, rather than clearly saying that a value was wrongly given.


2. = Syntax Validation Bypass (Potential Validation Bug)

There is currently no coverage or test for what happens with /webrtc=value or /webrtc-direct=value. There are strong indications from code review (see WEBRTC_TEST_REPORT.md) that these are silently accepted as valid, which is a true validation bug. These addresses should not be accepted for tag-only protocols.

Example of problematic cases:

Multiaddr("/webrtc=value")            # Should fail, may incorrectly succeed
Multiaddr("/webrtc-direct=foo123")    # Should fail, may incorrectly succeed

Steps to Reproduce

  1. Try parsing: /webrtc/value and /webrtc-direct/value
    • Observe error message is unhelpful ("unknown protocol: value") instead of "does not take an argument".
  2. Try parsing: /webrtc=value and /webrtc-direct=foo
    • Check whether these are accepted or rejected. If accepted, it's a serious bug.

Expected Behavior

  • An address like /tag (for tag-only protocols) should be accepted.
  • An address like /tag/value or /tag=value should fail with an error message:
    Protocol 'tag' does not take an argument
    
  • No silent acceptance of /tag=anything should occur.

Actual Behavior

  • /tag/value is rejected, but with a bad error message ("unknown protocol: value").
  • /tag=foo is either accepted (validation bug) or produces unclear output—needs confirmed/covered by tests.

What Should Be Fixed

  • Improve validation and error reporting for tag-only protocols:
    • If given a value via /tag/value or /tag=value, raise a clear error: "Protocol '' does not take an argument"
  • Add/extend tests:
    • Reject /webrtc=value, /webrtc-direct=value, /quic=abc, etc with correct error.
    • Ensure /protocol/value gets correct error.
  • (Stretch) Audit all tag-only protocols in protocol table for this behavior.

@seetadev @lla-dane I would like to work in this issue, I discovered it after testing the webrtc_examples.py
with @Nkovaturient

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions