Complete ice server url validation

[dontcallmedom]

close #2912

---

Preview | Diff

[dontcallmedom]

(the CI error is because we don't have tests for this; as noted in #2950 this is only a continuation of the lack of test for this change; see also #2997)

[dontcallmedom]

as discussed in #2997 (comment), reusing the application/x-www-form-urlencoded parser means making ?&transport=udp parsable; an alternative would be to instead do the split on = ourselves (rather than invoking the URL algorithm), limiting the set of acceptable query strings to ?transport=udp and ?transport=tcp (which would align better at least with the libwebrtc implementation). happy to change the PR in that direction if that's the preferred path.

[jan-ivar]

... reusing the application/x-www-form-urlencoded parser means making ?&transport=udp parsable

Less custom URL parsing seems in line with being "consistent with how we treat URLs elsewhere in the platform.". #2660 (comment)

an alternative would be to instead do the split on = ourselves (rather than invoking the URL algorithm), limiting the set of acceptable query strings to ?transport=udp and ?transport=tcp

OTOH, if this simple string compare lets us keep this in REC, why not do that for now, and add application/x-www-form-urlencoded back in later?

That seems a reasonable way to increment here to me.

[jan-ivar]

Are there any URLs that would reveal differences in parsing of the first part of the url (ahead of the ?) ?

[dontcallmedom]

I've switched to using a simple string comparison; I'm not sure using application/x-www-form-urlencoded parsing buys us much when it is not clear the RFC means it that way.

[jan-ivar]

Yeah that algorithm supports multiple query parameters whereas our RFC does not, so it's arguably odd to support & at all