Bug 339 - Browser able to access localhost without Internet connectivity
: Browser able to access localhost without Internet connectivity
Status: RESOLVED WORKSFORME
Product: Browser
User interface
: 5.0-beta2
: All Maemo
: Low enhancement with 5 votes (vote)
: ---
Assigned To: unassigned
: browser-bugs
: http://localhost:8000
: ITOS2007HE-garage
: 1767
:
  Show dependency tree
 
Reported: 2005-12-21 01:23 UTC by Martin Grimme
Modified: 2010-04-02 10:03 UTC (History)
6 users (show)

See Also:


Attachments
netcat deb (65.10 KB, application/x-debian-package)
2006-11-21 20:09 UTC, tuukka.tolvanen
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Martin Grimme (reporter) 2005-12-21 01:23:50 UTC
I want to run a wiki on the 770 for taking notes. The browser, however, cannot 
access the local wiki (http://localhost:8000) while being offline. 
localhost should always be available.
Comment 1 Maemo QA (deprecated) 2006-05-03 15:42:15 UTC
Claiming ownership.
Comment 2 Maemo QA (deprecated) 2006-05-03 15:44:06 UTC
Martin, could you please provide some more info what kind of a setup you're
using so that I can start to work on this one, i.e. which wiki, etc.
Comment 3 tuukka.tolvanen nokia 2006-11-21 20:09:04 UTC
Created an attachment (id=145) [details]
netcat deb

here's a netcat deb. you can use e.g.
    echo 'hello world' | netcat -l -p 80 -q 1
from x terminal as a test server (once for each request)
Comment 4 Timothy J. Miller 2007-03-02 06:08:22 UTC
Present also in OS2007 on the N800.  Running MoinMoin bound to localhost; Opera
requires network to 
access.
Comment 5 Timothy J. Miller 2007-03-02 06:15:58 UTC
FWIW, MoinMoin Desktop only needs cgi, SocketServer, SimpleHTTPServer, and
BaseHTTPServer to run.  
They can be placed in the same directory with moin.py.
Comment 6 Allan Doyle 2007-06-05 23:40:20 UTC
I'd like to add my name to the list of people hoping that this gets fixed! I'm
running a python webserver onboard the N800 and access it using the Maemo
browser, even when there is no established WiFi connection.

See also http://maemo.org/pipermail/maemo-developers/2007-May/010076.html
Comment 7 timeless 2007-08-06 20:50:58 UTC
for reference, an evil and inappropriate hack has been added for the microb
engine, and will be available in the next release (yes, I know, you can't run
microb on 770, that might be a fixable problem, but at the current release
doesn't have the fix anyway).

If this Bugzilla were similar to ones I control, bug 1605 would be a duplicate
of this bug. I'm sorry for all the people watching/voting for this bug that
they were ignored etc.

I'd like to encourage people to vote for bug 1767 as it's the correct way to
fix this for all applications.

In the interim, I believe you can use any *non* maemo platform application
(i.e. any sane application, such as minimo) and browse happily.

maemoqa: why wasn't this bug imported?? [note: don't bother importing it now,
it's way too late]
Comment 8 timeless 2007-09-16 00:35:02 UTC
*** Bug 1605 has been marked as a duplicate of this bug. ***
Comment 10 timeless 2007-11-21 19:30:35 UTC
oh, as it happens, i eventually gained control of Bugzilla. Unfortunately that
doesn't include engineering.

We're stuck waiting for ICD to fix their bug.
Comment 11 Mike C 2007-11-30 15:36:49 UTC
As noted in 1610 (closed as duplicate), this does not just affect the use of
servers running on the device (such as MemoWiki) but also prevents the reading
of static HTML _files_ (such as documentation).

It should therefore be very easy to recreate...

mfc
Comment 12 timeless 2007-12-04 17:21:32 UTC
-- If you are here, you might be just looking for a lesson on Bugzilla it's at
the end of this comment (comment 12), you click comment 13 and then scroll up
if you want to skip the technical bits in the middle of this comment. --

For the record, recreating this problem is now (and has been since around when
comment 7 was written) "relatively hard".

The following steps to reproduce "workforme" in os2008 (target milestone: 4.0).
However the bug is not actually fixed, we merely worked around this as I
perhaps obliquely mentioned in comment 7.

Here's the steps I used:
1. open X Terminal
2. cd ~/MyDocs/.documents/
3. cp -r /usr/share/browser/home_page .
4. press the power button
5. offline mode
6. ok
7. open browser
8. app menu
9. web page>open file...
10. tap home_page
11. if the folder doesn't open, tap it again (...)
12. tap index
13. if it doesn't open, tap it again (...)

you need to view actual results using a monospace font.
actual results:                       _
                    POWERED BY | /  _/_ \
                    mozilla    | \ _/   /

             Google Images Groups News
[                                               ]
                    [ Google Search ]
                          .
                    _  tm | N [=]KIA
                  maemo   |     Nseries

A technical explanation of why this "worksforme"

http://timeless.justdave.net/mxr-test/garage/source/browser/mozilla/trunk/microb-eal/src/

contains the relevant files as far as i understand.

void g_mozilla_connectivity_handle (GMozillaEngine *self, gint event)
g_mozilla_connectivity_connect (gpointer data, gboolean reconnect)

http://timeless.justdave.net/mxr-test/garage/source/browser/mozilla/trunk/microb-eal/src/gmozillaengine.c
 281 g_mozilla_engine_load_url (GMozillaEngine *self, const gchar *url)
 282 {
 291         send_progress_signal(self, START_LOADING, url, 0, 0);
 293         if (!g_mozilla_connectivity_is_connected() &&
!protocol_is_local(url) && !host_is_local(url)) {

note: protocol_is_local and host_is_local.

 294             if (g_mozilla_connectivity_connect(self, FALSE)) {
 295                 return;
 296             }
 297         }

 300         gtk_moz_embed_load_url(GTK_MOZ_EMBED(self->engine), url);

 151 static gboolean
 152 protocol_is_local(const gchar *uri)
 153 {
 154     if (!*uri)
 155         return FALSE;
 156
 157     return '/'==uri[0]
 158            || g_str_has_prefix(uri, "file:")

the URL in my location bar is:
file:///home/user/MyDocs/.documents/home_page/index.html

which would be ok.
unfortunately, from reading the code, it's clear that
File:///home/user/MyDocs/.documents/home_page/index.html
or
FILE:///home/user/MyDocs/.documents/home_page/index.html

would trigger the dialog (and in fact, it does).

 159            || g_str_has_prefix(uri, "data:")
 160            || g_str_has_prefix(uri, "about:")
 161            || g_str_has_prefix(uri, "upnp:")
 162            || g_str_has_prefix(uri, "obex:");
 163 }

also, any other random un-whitelisted protocol will get foolish behavior.

I think the right test is basically
1. parse for not more than 6 characters stopping at the first :
2. lowercase
3. compare against ftp,http(s),gopher
* gopher only if the engine is built w/ gopher.
4. return true only if compare in 3 is false

note: when I told someone that their hack was really broken, i really meant it.

 206 static gboolean
 207 host_is_local(const gchar *uri)
 208 {
 209     const gchar *elem = NULL;
 210     gchar *host = NULL;
 211     gint i = 0, len;
 212
 213     if (!*uri)
 214         return FALSE;
 215
 216     host = uri_get_host(uri);
 217
 218     for (elem = localhosts[0]; elem != NULL; elem = localhosts[++i]) {
 219         len = strlen(elem);
 220         if (strncasecmp(elem, host, len) == 0) {
 221             g_free(host);
 222             return TRUE;
 223         }
 224     }
 225
 226     g_free(host);
 227     return FALSE;
 228 }

 62 static const gchar *localhosts[] = {
 63     "localhost",
 64     "127.0.0.1",
 65     "127.0.1",
 66     "127.1",
 67     "[::1]",
 68     NULL
 69 };

this covers a number of average cases.

Tested using week 42 (this is the n810 first shipping week, the code has not
changed in a while)

The technical reason that this bug is not resolved as worksforme:
the following all work as testcases:
File:///home/user/MyDocs/.documents/home_page/index.html
FILE:///home/user/MyDocs/.documents/home_page/index.html
http://127.0.1.1
http://localhost.localdomain
callto:x
mailto:x

Again, the right fix is the bug to which this bug is dependent (bug 1767). When
it's fixed, the browser could remove its hack (or ifdef it to os's w/ the
broken code).

-- what follows is more of a lesson in Bugzilla --

When you reach a bug and are curious about it's status, there are a few things
to check, probably in this order:
1. Dependencies (described below)
2. Target milestone (in this case, at this time, it's "Future", because of the
dependency, as the bug is not fixable by the browser team, we're trying to give
people a hint that we can't and aren't going to try to fix it anytime soon)
3. Assigned to (in this case, at this time, it's "unassigned", because it
doesn't make sense to expect a browser engineer to work on a bug which merely
requires work from another team)

So, what happens?
1. you load bug 339
2. you scroll just past the attachments block to where you see "Bug 339 depends
on ..."
3. you decide you want to see the bigger picture
4. click "Show dependency tree"
5. which loads https://bugs.maemo.org/showdependencytree.cgi?id=339
6. at this time, you will see something that looks like this:
Bugs that bug 339 depends on
( view as bug list)

   * 1767 [---, nobody@maemo.org] - trying to connect to "localhost"
while offline/disconnected triggers network search.

Bugs that bug 339 blocks

None

7. If you now load:
https://bugs.maemo.org/showdependencytree.cgi?id=1767
(you can get this by clicking the link to bug 1767 and then clicking its
Dependency Tree link)
(in newer Bugzillas, you would click the tree icon next to the interesting bug)

You'll see:

Dependency tree for Bug 1767
trying to connect to "localhost" while offline/disconnected triggers
network search
       Max Depth:

Bugs that bug 1767 depends on

None
Bugs that bug 1767 blocks
( view as bug list | change several)

   * 339 [Future, nobody@maemo.org] - browser needs internet
connectivity for accessing localhost.
   * 1766 [---, nobody@maemo.org] - RSS feed reader requires a
network to access local feeds via http.

i.e., bug 1767 is a blocker for bug 339 and bug 1766.

If you see someone say that a bug is "blocked" by another bug, this is what it
means. This bug is blocked by bug 1767. If you see someone say that a bug is a
blocker, then it's in the other position (bug 1767 is a blocker ...).

Note: ranting in bugs that bug X is critical or that it's blocking another bug
is not helpful.
If you would like to ask for more information, please
1. use IRC
2. use direct email to people listed as being involved in this bugzilla
3. use directed email to individual active Bugzilla users (pick the helpful
ones)
4. use directed email to individual engineers only if the other methods fail

- In all cases, please be patient and polite.
- Just because you're awake doesn't mean someone else is.
 - In some cases, people may be traveling, or on vacation (vacations for
Europeans tend to be 4 weeks long, i.e., an entire month, and while they're
typically in the summer or winter, mine was in the fall).
- And please be polite, and please please accept that you are not the only
person or customer in the world.
- Nokia is trying to improve its openness, but if enough customers scare enough
managers, engineers, testers, etc., then this can fail.
Comment 13 timeless 2007-12-24 18:26:58 UTC
i filed bug 2653 based on the logic errors i described in comment 12.
Comment 14 Quim Gil nokia 2008-12-05 13:16:03 UTC
This is now considered an enhancement request, see Bug 1767 Comment 9
Comment 15 Mike C 2009-02-10 17:57:59 UTC
Why 'low'?  This makes the device unusable for talking to local TCP/IP-based
applications when offline (e.g., when on a plane, in an automobile, etc.). 

My N800 has been sitting on a shelf at home, used only there, and will remain
so until this bug is fixed.  <sigh> 

And I originally reported this bug -- but am not permitted to undo the change
to Low it seems (fourth attempt).
Comment 16 Andre Klapper maemo.org 2009-02-10 18:35:30 UTC
"Low" because it reflects the reality. This bug depends on bug 1767.
Bug 1767 comment 7 describes that currently no developer is working on this, as
unfortunate as this fact might be considered.
Feel free to vote for bug 1767 if you have not done yet.
Comment 17 darkblue_b 2009-02-10 18:45:05 UTC
darkblue_B: I could step through your scenarion with you if you like.. I have
an N800
  timeless: ok, 1. use app manager or something to install a web server
  timeless: i have no idea what web servers are available, sorry
darkblue_B: I use lighttpd
darkblue_B: from a .deb
  timeless: sounds good
darkblue_B: http://dpaste.com/118974/
darkblue_B: thats where I got mine
darkblue_B: it was pre configured, worled perfectly
  timeless: ok
  timeless: 2. visit http://127.1/
darkblue_B: I had tried a full apache before.. it worked but not as neat 
  timeless: (while you're connected to a working network)
  timeless: does it load?
darkblue_B: ok
darkblue_B: trying
darkblue_B: well sort of.. an error page - says 400 Bad Request
  timeless: ok
  timeless: try http://localhost/
  timeless: we''ll call that '3.'
darkblue_B: id you mean 127.0.0.1 ?
darkblue_B: that gives 4040 - Not Found
darkblue_B: 404
  timeless: 127.1 is an alias for 127.0.1 which is an alias for 127.0.0.1
darkblue_B: well ok, now trying localhost
darkblue_B: so I forgot to put an index.html in the base directory
darkblue_B: now with an index.html, localhost has worked
darkblue_B: trying the others again
darkblue_B: 127.0.0.1 works
darkblue_B: 127.1 oes not
  timeless: ok, click on the wifi indicator in the status bar
  timeless: click connectivity settings
  timeless: what options do you see?
  timeless: (my tablet doesn't speak en-FI, and it's elsewhere, so we're
pretending i'm blind)
darkblue_B: my net name
darkblue_B: disconnect
darkblue_B: Change COnnection ...
darkblue_B: Connectivity Settings...
  timeless: sorry, click Connectivity Settings...
darkblue_B: 4 lines
  timeless: now what do you see :)
darkblue_B: two tabs, General and Idle Times
  timeless: what's on the general tab
darkblue_B: Connect Automaticaly popup menu (4 choices)
  timeless: what are the chioces
darkblue_B: Search Interval popup (currently disabled)
  timeless: gah, my typing sucks
  timeless: oh, so connect automatically is 'no' or 'none' or something?
darkblue_B: Always ask / WLAN / Phone / Any Connection
  timeless: oh, always ask?
  timeless: alright
darkblue_B: y
  timeless: close the dialog
  timeless: click the connectivity icon and click disconnect
darkblue_B: Disconnect? (dialog)
darkblue_B: answer yes
  timeless: yes
darkblue_B: blinking
  timeless: close the browser
  timeless: open the browser
  timeless: try to load http://localhost
darkblue_B: new browser window
  timeless: oh, yes, technically, tap the globe, tap open new browser window
darkblue_B: yes - page loads
  timeless: ok
  timeless: can you record the steps you took and the settings you observed
  timeless: (be detailed)
darkblue_B: we just did.. this IRC record
  timeless: https://bugs.maemo.org/show_bug.cgi?id=339
  timeless: as a comment there
  timeless: preferably cleaned up
darkblue_B: bugs?
darkblue_B: that it did or didnt ?
  timeless: it's working as it should
darkblue_B: is a bug
  timeless: you said the apge loaded, right? it didn't ask to connect or
anything, right?
  timeless: oh, oops, last thing
  timeless: close the browser
  timeless: press the power button
  timeless: select offline mode
  timeless: click ok
  timeless: globe>open new browser window
  timeless: load http://localhost/
  timeless: does it work?
darkblue_B: offline mode in effect.. page loaded
  timeless: great
darkblue_B: I should add the OS verison.. easy way to tell?
  timeless: please clean up the log into steps+results
  timeless: open control panel
  timeless: there's an 'about product'
  timeless: the version is at the top of that dialog
darkblue_B: yes, found it
  timeless: you can also get it from /etc/osso_software_version (which you can
open from the web browser)
darkblue_B: oh ok
darkblue_B: 5.2008.43-7
  timeless: great, that's the right version :)
darkblue_B: yeah.. DIABLO xxxxx
Comment 18 Andre Klapper maemo.org 2009-02-10 18:49:15 UTC
a clean step-by-step would be more welcome.
last comment is just very noisy.
Comment 19 Quim Gil nokia 2009-09-28 09:57:16 UTC
I fail to see why this isn't a duplicate of 1767. In practice, if bug 1767 is
fixed this one would be fixed automatically, isn't it.

Anyway, just a heads up to say that I'm asking for use cases and problems this
feature would solve at Bug 1767 Comment #13
Comment 20 Andre Klapper maemo.org 2009-09-28 12:22:50 UTC
(In reply to comment #15)
> Why 'low'?  This makes the device unusable for talking to local TCP/IP-based
> applications when offline (e.g., when on a plane, in an automobile, etc.). 

Please list those exact apps in bug 1767. Thank you.
Comment 21 maemo 2010-04-02 03:31:47 UTC
this bug is similar to https://bugs.maemo.org/show_bug.cgi?id=1767
Comment 22 timeless 2010-04-02 10:03:26 UTC
maemo@assetburned.de: since you appear entirely incapable of reading bugs and
instead insist on spamming them, i've decided to mark this bug as WORKSFORME.

PLEASE DO NOT SPAM BUGS WITHOUT READING THEM.

If you had actually read this bug, especially comment 12, you'd be aware of how
bugzilla works and what the two bugs mean.

Since you're incapable and unwilling to use bugzilla properly, i'm just going
to simplify my life by marking this bug as WORKSFORME and complaining that you
spammed two bugs. DO NOT SPAM BUGS.

FWIW, crashanddie confirms that w/ a 'server running on 80', this still
worksforme. Roughly for 'most' users the browser is able to access localhost
without internet connectivity (if localhost is actually running something on
that port). When someone actually fixes bug 1767, someone can file a new bug to
clean up the browser code and get it to use the new api.