Hostname
Warning: You are browsing the documentation for Symfony 6.0, which is no longer maintained.
Read the updated version of this page for Symfony 7.1 (the current stable version).
Hostname
This constraint ensures that the given value is a valid host name (internally it
uses the FILTER_VALIDATE_DOMAIN
option of the filter_var PHP
function).
Applies to | property or method |
Class | Hostname |
Validator | HostnameValidator |
Basic Usage
To use the Hostname validator, apply it to a property on an object that will contain a host name.
1 2 3 4 5 6 7 8 9 10
// src/Entity/ServerSettings.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class ServerSettings
{
#[Assert\Hostname(message: 'The server name must be a valid hostname.')]
protected $name;
}
1 2 3 4 5 6
# config/validator/validation.yaml
App\Entity\ServerSettings:
properties:
name:
- Hostname:
message: The server name must be a valid hostname.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
<!-- config/validator/validation.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<constraint-mapping xmlns="http://symfony.com/schema/dic/constraint-mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping https://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">
<class name="App\Entity\ServerSettings">
<property name="name">
<constraint name="Hostname">
<option name="message">The server name must be a valid hostname.</option>
</constraint>
</property>
</class>
</constraint-mapping>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// src/Entity/ServerSettings.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;
class ServerSettings
{
public static function loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('name', new Assert\Hostname([
'message' => 'The server name must be a valid hostname.',
]));
}
}
The following top-level domains (TLD) are reserved according to RFC 2606 and
that's why hostnames containing them are not considered valid: .example
,
.invalid
, .localhost
, and .test
.
Note
As with most of the other constraints, null
and empty strings are
considered valid values. This is to allow them to be optional values.
If the value is mandatory, a common solution is to combine this constraint
with NotBlank.
Options
groups
type: array
| string
It defines the validation group or groups of this constraint. Read more about validation groups.
message
type: string
default: This value is not a valid hostname.
The default message supplied when the value is not a valid hostname.
You can use the following parameters in this message:
Parameter | Description |
---|---|
{{ value }} |
The current (invalid) value |
{{ label }} |
Corresponding form field label |
payload
type: mixed
default: null
This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.
For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.
requireTld
type: boolean
default: true
By default, hostnames are considered valid only when they are fully qualified
and include their TLDs (top-level domain names). For instance, example.com
is valid but example
is not.
Set this option to false
to not require any TLD in the hostnames.
Note
This constraint does not validate that the given TLD value is included in the list of official top-level domains (because that list is growing continuously and it's hard to keep track of it).