@imiroslavov just asking in case this is merged and we need to document it: must the callback value be escaped somehow before including it to the DSN?

For example, in some parts of the docs we say this for the DATABASE_URL DSN:

If the username, password, host or database name contain any character
considered special in a URI (such as +, @, $, #, /,
:, *, !), you must encode them.

Thanks.

@javiereguiluz The query parameters of the DSN are passed to parse_str so yes. The callback URL can/must be entirely escaped.

If #34654 is merged before this PR it will require additional work.

@Nyholm Sorry for the late reply. The idea initially sounded good but right now I see only downsides.

1. Hard-coding the URL is a bad practice.
2. In most of the cases you will want to track the result of the callback in a previously created database record (preliminary record). The most adequate way is to generate a callback URL that contains the ID of that record which is not possible in this PR. (e.g create preliminary SMS record with status "pending". Then update it to "sent", "delivered" etc. depending on the callback data)
3. After this PR was submitted an adapter for "ovhcloud" was added which doesn't support different callbacks per request.

I'm stuck at this point. Maybe a callback envelope will be a better solution but not implementing it for all adapters doesn't sound right.

I will have enough free time to work on this next week so I'm open for suggestions.

I would add that the payload of the callback wouldn't be the same depending on the provider. I propose to close for now until we have a better idea.

@fabpot The provider can also be added to the callback URL but that would lead to compromises and probably more problems in the user's code, so closing the PR is the best option.