This is a conceptual issue or an enhancement request addressing the following case.
Assume we are using the default configuration and there is no captive portal present. If the server successfully returns a response with some unexpected content that does not contain "Success" as a substring Hyperconnectivity will consider the response as a failed one despite of being successful. In general should we consider having successful responses as a connected state regardless of status code and content if there is no captive portal present?
I think it is worth considering to add checks about the response's status code here. If we should consider other (status code,response data) pairs than the (200,expected-string) as acceptable, searching for the expected string should be dependent on status code.
Would you consider refining the default behaviour in that way if it makes sense to you?
This is a conceptual issue or an enhancement request addressing the following case.
Assume we are using the default configuration and there is no captive portal present. If the server successfully returns a response with some unexpected content that does not contain "Success" as a substring Hyperconnectivity will consider the response as a failed one despite of being successful. In general should we consider having successful responses as a connected state regardless of status code and content if there is no captive portal present?
I think it is worth considering to add checks about the response's status code here. If we should consider other (status code,response data) pairs than the (200,expected-string) as acceptable, searching for the expected string should be dependent on status code.
Would you consider refining the default behaviour in that way if it makes sense to you?