Re: [PATCH] core: add internet connectivity check

[Thomas Bechtold <thomasbechtold jpberlin de>]

Hi Marcel,

On 22/11/11 12:21, Marcel Holtmann wrote:
> Hi Thomas,
>
> > > > i just want to summarize the discussion about the response handling so
> > > > we can decide which solution we want to use.
> > > > mentioned solutions are:
> > > >
> > > > 1) check http status-response 204 (or any other) (chromiumos method)
> > > > 2) check content for a specific http header (connman method)
> > > > 3) check start of content (implemented in patch V3)
> > > > 4) check complete content
> > > > 5) check http status-response 200 (creates false positives for hotspots)
> > > > 6) check content with a regex (tie us into a specific regex lib)
> > > >
> > > > 5+6 are already declined.
> > > >
> > > > i prefer solution 3 because it's more flexible than 1) and produce fewer
> > > > traffic than 2).
> > >
> > > actually 2) would produce fewer traffic than 3) since the HTTP headers
> > > are transmitted before the content.
> >
> > You are right. i mixed up http headers with html headers.
> >
> > > If you just want some stupid check, then looking at the headers is
> > > simpler since otherwise you have to deal with HTTP 1.0 vs 1.1 and have
> > > to have support for chunked encoding.
> >
> > i'm not sure but i think libsoup handles 1.0/1.1 and chunked encoding.
> >
> > i like the idea of a plain text file because it's more easy to setup on
> > server side than http headers.
>
> creating server side HTTP headers is as simple as plain text files. We
> decided for the HTTP headers since it a lot more logical then doing some
> random plain file comparison.

if you have a managed server (without root access) i think it's not so 
easy to send http headers but it's simple to deliver a plain text file.

> Actually the HTTP header makes a lot more sense since once you received
> the valid one, you can just terminate the HTTP request and do not have
> to deal with downloading the whole file. Keep in mind that some hotspots
> have a lot of HTML in there. In case you care on how fast your overall
> connection setup time is. If you don't, then it does not matter of
> course.

right. imo the speed/traffic is an important argument.

> > > However if your long term goal is WISPr support, then you have to look
> > > at the whole page anyway. There is no guarantee that the WISPr XML is at
> > > the beginning. Some providers actually just attach it to the end.
> >
> > personally i don't care about WISPr. I just want to know if i have a
> > working internet connection.
>
> Doing this without also handling WISPr seems rather pointless. I prefer
> my system to automatically log me into a hotspot if I have access
> credentials for it.

why do you think that's pointless?
eg i have a embedded device with an usb-gadget (detected as ethernet 
device). when i connect my pc with the device over usb, the device has 
no internet connection. but when i configure my pc to forward some 
traffic from the device, the device has internet connection. for this 
usecase it's very nice to check the connectivity.
the device can do different task if a connection is available.

Cheers,

Tom