On Mon, 2018-02-12 at 18:06 +0100, Aleksander Morgado wrote:
If we're going to use a 'no content' URL (HTTP 204) to check connectivity, do not try to match prefix when the content is being received. This issue was making the check not work properly, as the content returned by the captive portal was assumed as expected (given that g_str_has_prefix(str,"") always returns TRUE!). Also, rework a log message that was being emitted on portal detection to avoid specifying that the reason is the content being shorter than expected, as that same logic now applies to the case where too much content is received and none was expected. Fixes: 88416394f8e0a51dae9f40a31ca0c8077f08808a --- Hey Thomas, Looks like the portal detection was broken with the previous implementation when using the HTTP 204 based logic :) Now tested with a real portal and this commit fixes the detection. Also reworked one of the logs dumped when the portal is detected, as it didn't make much sense when the HTTP 204 based logic was used. I reused the same message that was being used in the other part of the code where the portal is also detected, hope that's not an issue (we're anyway printing the expected response code, so it would be clear from reading the logs which one of them both we're seeing). Let me know what you think.
Hi Aleksander, looks right to me (again) :) merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a25d2e0a17636c799bc7f40e443f7c0131ba8f8d best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part