[Feature Request] Custom per-URL response validation

[benasher44]

We have some API hosts that have a general health check that we can use to check connectivity, and then we have other hosts that are setup with a special string just for the captive-portal check. As it stands, the current Connectivity API doesn't allow mixing/matching hosts that can return different response, in a strict way. You can accomplish this to some degree with regexp response validation, but the regexp you write may have to be too permissive to allow the different responses.

[benasher44]

One way to do this without over-complicating the API would be to allow setting a block that gets called (with the URL that was requested and the response) to perform custom validation of all URLs. This block could return a result like this:

enum CustomValidationResult {
    /// response for the url was validated successfully
    case valid

    /// response for the url was determined to be invalid
    case invalid

    /// perform the default / non-custom validation
    case performDefaultValidation
}

[benasher44]

I'm also happy to do the work here. I mostly just want to agree on the idea & API before jumping in :)

[rwbutler]

Hi Ben,

Sorry for the delay in getting back to you - thanks for the suggestion :) I've been having a think about this as well and one of the things I'm a little concerned about is the main file / class length is beginning to approach a length that will trigger linter warnings so it might be an idea to create a protocol e.g. ConnectivityResponseValidation and then enable users to create a custom response validator which conforms to the protocol - this would avoid increasing the file / class length. A property e.g. responseValidator could be set on the Connectivity object enabling users to set their own implementation as the validator to be used. How does this sound?

[benasher44]

Sounds good to me! Similar behavior though? Custom validator can opt to handle the response or pass it back to the default validation to handle?

[rwbutler]

Great 👍🏻 I'd be happy with that solution.

[rwbutler]

One thing I thought of was - currently ConnectivityResponseValidator switches behavior based on the response validation mode passed in to the initializer (it will use string matching or regex). It might be a nice idea to split these out into separate validators conforming to the ConnectivityResponseValidation protocol i.e. one for string matching, one for regex etc. That way in a custom validator you would be able to invoke the response validator of your choice depending on the URL you receive. If the only option is to fallback to a single default validator then the behavior of the default validator wouldn't be able to change per URL because the settings remain the same (the validation mode would remain unchanged for the default validator). Having different validators conforming to the protocol would also mean that the user could make use of any of these simply by assigning the relevant validator to the responseValidator property.

[benasher44]

Sounds good to me! Will take a crack at this soon

[benasher44]

The initial PR is here: benasher44#1. I'll open a fresh one against this repo with tests once we discuss and also resolve what to do about #27.

[benasher44]

Actually I don't see tests anywhere… would you like some tests added?

[rwbutler]

Thanks - I've merged that in now. Apologies, yes you are correct, I've been meaning to add some tests for a long time now but had been a little rushed off my feet. Now that you've reminded me to come back to this, I'll start adding some too.

[rwbutler]

I've just created a release 3.2.0 containing your PR 👍🏻

[benasher44]

Awesome thanks!