>>Unfortunately there are numerous of ISP's or organizations which >>want to modify/strip X-ConnMan-Status-header away from the >>http-responses even the connection is otherwise just fine (eg. no >>portals). However they do not modify http-status response codes and >>that's when the "204" comes in handy. With this patch ConnMan-users >>can use alternative way to check whether their devices are >>actually "online" >So the ISP is doing dirty tricks with the HTTP reply, I just wonder why >they strip away the headers in this case.
Well you never know what they do in between, sometimes they even modify user-agent-header. (Yes, I've seen this). >Your solution to return 204 sounds quite an ugly hack to me. How can we >be sure that the return code is really from your server if we do not >have the X-ConnMan-Status in the header? Are you really sure that 204 is >never returned by any proxy or other network element? You can't be 100% sure of it but there is no reason why would any proxy or anything else return 204 as it's required by RFC2616 that it can't have any message-body in the response. [1] "The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields." It also means that client should not update the current view -> no gain to send 204 as a reply. Actually Android-devices are using the same method to detect the captive portal through "http://clients3.google.com/generate_204";. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Br, Pasi _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
