maemo.org Bugzilla – Bug 339
Browser able to access localhost without Internet connectivity
Last modified: 2010-04-02 10:03:26 UTC
You need to log in before you can comment on or make changes to this bug.
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.
Claiming ownership.
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.
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)
Present also in OS2007 on the N800. Running MoinMoin bound to localhost; Opera requires network to access.
FWIW, MoinMoin Desktop only needs cgi, SocketServer, SimpleHTTPServer, and BaseHTTPServer to run. They can be placed in the same directory with moin.py.
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
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]
*** Bug 1605 has been marked as a duplicate of this bug. ***
https://garage.maemo.org/tracker/index.php?func=detail&aid=1425&group_id=164&atid=681
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.
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
-- 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.
i filed bug 2653 based on the logic errors i described in comment 12.
This is now considered an enhancement request, see Bug 1767 Comment 9
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).
"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.
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
a clean step-by-step would be more welcome. last comment is just very noisy.
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
(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.
this bug is similar to https://bugs.maemo.org/show_bug.cgi?id=1767
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.