Description

Feature Request

Currently, theAssert\Url constraint supports two options related to URL schemes:

• protocols: An array of acceptable protocols. Defaults to['http', 'https'].
• relativeProtocol: A boolean that allows the scheme to be omitted entirely when set totrue.

However, there is no built-in way to require that a scheme is presentwithout restricting which scheme it is.

Proposed Solution

Introduce a new option to theUrl constraint:

#[Assert\Url(['allowAnyProtocol' =>true])]

WhenallowAnyProtocol is set totrue:

• A scheme isrequired in the URL.
• The value ofprotocols is ignored.
• The URL is otherwise validated as a well-formed absolute URL.
• The option is mutually exclusive withrelativeProtocol, which would continue to allow omission of the scheme whentrue.

This would allow developers to validate that a string is a well-formed absolute URLwith a scheme, without having to enumerate every possible valid or custom scheme.

Rationale

This is useful in scenarios where URLs may use custom schemes (myapp://,vscode://, etc.) and where maintaining a hardcoded list of all acceptable protocols is impractical or unnecessary. For example:

• Validating deep links for mobile apps
• Accepting third-party URLs with non-standard schemes
• Supporting generic configuration that may include any URI scheme

Backward Compatibility

• The newallowAnyProtocol option would default tofalse, preserving current behavior.
• If bothprotocols andallowAnyProtocol are set, a logic exception can be thrown to avoid ambiguity.

Summary

This small enhancement would provide much-needed flexibility for developers using theUrl constraint in modern, protocol-diverse environments, without requiring a complete rewrite or workaround.

Thanks for your consideration!

Example

No response