Hi,
On Tue, 2014-04-22 at 12:37 +0000, Pasi Sjöholm wrote:
> >>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).
If eager proxies start removing/modifying end-to-end stuff, there is
nothing one can basically do to counter such an approach.
> >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.
There is no message body of any practical purpose coming back from
ipv[46].connman.net. Everything useful is in the headers. If the headers
are removed, there's not much ConnMan can do about it. How is ConnMan
better off with the server sending 204s? Why wouldn't any eager proxies
be able to generate 204s due to whatever unimaginable reason themselves?
And still strip off all the headers?
> [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";.
From stackoverflow.com it seems that Android devices are doing more or
less the opposite here. They seem to be informing the (google) service
of what can be expected. As a side effect, if they think they can
communicate with that URL, DNS and routing works.
OTOH ConnMan will claim the device is connected once there is IP
addressing, 'online' means a successful round-trip to
ipv[46].connman.net with said headers not stripped off. Android devices
don't make this distinction of two connected states anyway.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
