Potential Issue with URL Decoding in DSN Handling

[roukmoute]

Symfony version(s) affected

>= 4.4

Description

There seems to be an inconsistency in the handling of special characters in the DSN within the Symfony Mailer component. According to the Mailer Documentation, special characters in the host (like /) should be URL-encoded. However, upon inspecting the source code, it appears that $parsedDsn['host'] is not URL-decoded.

How to reproduce

• Create a DSN string with special characters like api.example%2Ffoo%2Fbar%2Fbaz, etc., in the host.
• Pass this DSN string to the Mailer component.
• Observe that the DSN parsing does not URL-decode the host.

Possible Solution

• Implement URL decoding for the host in the DSN parsing logic at this point in the code.

Additional Context

I am willing to create a Pull Request to address this issue if the Symfony team agrees that this behavior needs correction.

[stof]

I don't understand why you want decoded / in the host. / are not valid in hosts when building a URL either. The host does not expect a URL. It expects a host.

[roukmoute]

Thank you for your prompt response @stof and for clarifying the situation. Following our discussion, I now understand that the main issue is the inability to configure a path in Symfony's DSN, as shown in the Dsn.php code. It appears that the current DSN structure does not accommodate the inclusion of a path.

With this in mind, I propose a two-step solution:

• Creating a First Pull Request: This PR would aim to add the capability to configure a path in the DSN. This would allow for greater flexibility and could address the current issue.
• Modifying a Specific File: The second PR would involve correcting the OhMySmtpApiTransport.php file, which currently contains a host with a path. This change would align the code with the new capability of the DSN to handle paths.

I am ready to work on these two Pull Requests if you believe this is an appropriate approach to address this issue. Please let me know your thoughts or your agreement to proceed in this manner.

[n0rbyt3]

There is only one thing that needs to be fixed: the documentation.

According to the specs, a hostname must only contain alphanumeric characters (a-z, 0,9) and hiphens (-). Thus, no decoding of this part ist required. But the docs does mention the host as part that may contain special characters.

So I totally agree with @stof: A hostname that contains a slash (/) is invalid since the slash is the path delimiter.

[roukmoute]

Thank you for pointing out the need to update the documentation @n0rbyt3. I agree that clarifying the specifications regarding hostnames is essential. However, I would like to emphasize that we should also consider addressing the other potential errors I mentioned.

For instance, take a look at this code in the OhMySmtpApiTransport.php file. If a port is configured here, the default host configuration becomes problematic. The reason is that the port, such as :8081, gets appended after /api/v1 in the URL, leading to an incorrect format.

Therefore, I believe we are adding these key action:

• Update the documentation to correctly reflect hostname specifications.

I look forward to contributing to these enhancements.

[n0rbyt3]

@roukmoute Good find. I guess the constant HOST did contain the hostname only in previous versions, so getEndpoint() worked as expected.

However, the class is deprecated since 6.2.

[carsonbot]

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

[carsonbot]

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

[carsonbot]

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!