Description

Feature Request

Currently, the Assert\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 to true.

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

Proposed Solution

Introduce a new option to the Url constraint:

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

When allowAnyProtocol is set to true:

• A scheme is required in the URL.
• The value of protocols is ignored.
• The URL is otherwise validated as a well-formed absolute URL.
• The option is mutually exclusive with relativeProtocol, which would continue to allow omission of the scheme when true.

This would allow developers to validate that a string is a well-formed absolute URL with 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 new allowAnyProtocol option would default to false, preserving current behavior.
• If both protocols and allowAnyProtocol are set, a logic exception can be thrown to avoid ambiguity.

Summary

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

Thanks for your consideration!

Example

No response