On 16/06/11 12:29, peasth...@shaw.ca wrote: > From: Scott Ferguson <prettyfly.producti...@gmail.com> > Date: Wed, 15 Jun 2011 23:12:59 +1000 <snipped> > >> Does it work with Lynx - Konqueror, Opera, Chrome, or any other web >> browser?? > > Dalton's address is 142.103.107.137. In these tests, file:///Category2.xhtml > and file://142.103.107.137/Category2.xhtml should have the same meaning. > > When these file URI are retrieved from the remote server, > elinks opens file://142.103.107.137/Category2.xhtml and > file:///Category2.html, > lynx and w3m open file:///Category2.html but not > file://142.103.107.137/Category2.xhtml
My understanding is that lynx doesn't support xhtml by default - it can though:- http://www.kolpackov.net/projects/lynx/xhtml.xhtml w3m only support xhtml 1.0 Try not using an xhtml file - I suspect you are complicating your tests. I'm not understanding why you are using the ip address - even localhost is redundant... with file:/// links localhost is the default root.... > and Iceweasel, Chromium and Opera open neither. Have yet to try Firefox and > Konqueror. Hmm - do you mean that you are using a local copy or the page served by shaw.ca?? If it's the latter, then they (sic) are displaying safe behaviour. You *did* change the restrictions in Iceweasel (about:config) didn't you? (sorry if you've previously clarified that - I haven't had time this evening to reread all the previous threads/posts.) > >> Wouldn't this whole process be simpler if you just had a local copy of >> the website - test there and then push the changes up to the production >> server? > > Web page editing is done at home and also at work. A local copy would have > to be kept at both sites. That introduces the problem of site consistency. It's a very common scenario. I'd hesitate to describe it as a problem. More a feature of sane, standard, site development. The usual procedure is to test on a non-public development server - only migrating the changes to the productions server when proven. I generally test changes on a server in a virtualbox machine before pushing them to the development server (belt and suspenders). For a static site such as yours I suggest you just tar.bzip /home/peter/public_html (on shaw.ca). Call it public_htmlxxxx.tar.bz2 where xxx is the date and time. Change control can be as simple as creating a file without contents using the date and time as a name before archiving. eg.:- $ touch `date | sed 's/ //g'` A later dated archive always replaces an earlier dated archive. And a changes text file can be used to keep track of versions. On my development and vb machines I just use mc for creating archives (they are headless and accessed with ssh). eg. from inside public_html select the menu (F2) in mc and choose "Compress the current subdirectory tar.bz2" you'll be prompted for a filename - the default will be "public_html" - just change it include the date and time. You'll wind up with /home/peter/public_html_instance.tar.bz2 > The simplest solution is to keep just one copy on flash storage and carry > it with me from one site to the other. There is already a CF card used > this way on the ETHNO systems. So I would be adding a second flash store. > Then I would have the primary copy of some files on the CF card and other > files on the flash used in the Debian systems. I prefer to avoid that. Good idea (avoiding that) - it robs you of a history of changes, and it's to easy to fail to include files, include files not needed. > Another possibility is to jettison the ETHNO systems and > use only a Debian system at each site. I have trouble jettisoning a simple > and reliable system which is really efficient for most elementary tasks. If it ain't broken.... > The file URI would be helpful if it worked. A compromise is to first open > the testing copy of Category2.xhtml on Dalton, using the Iceweasel or > Chromium > application menu. As long as the window remains open, the file can be > retested with the refresh button. One click. Yes. You'll still retain the last but one change (~) > > Meanwhile, I'll pursue fixing the response to the file URI. > >> As you are only serving static files you might >> even be able to use rsync or sftp/fish to achieve the same thing. > > ftp is good for home to shaw.ca. By extension through the VPN tunnel, > ftp also works from the "work" site to shaw.ca. FTP is fast! Even faster when it's only moving a tar.bz2! <snipped> > >> If the page with the file link (file:///) is being served by a *remote* >> webserver - you need to turn off the restriction in the browser (as you >> have already done). Understanding that file link will actually point to >> a location on the viewing machine. > > Exactly the feature appearing not to work as it should according to Mozilla > Security Policy. You may have found a difference between Firefox and Iceweasel.... > >> Back before Firefox it used to be considered amusing to put a link in a >> publicly accessible web page like file:///C:/autoexec.bat and tell the >> visitor the world can view their file system (each person loading the >> page sees their own file system). That is what the default setting in >> Iceweasel prevents. > > Yes, "each person loading the page sees their own file system". > "the world can view" implies public access; I'm fairly sure you didn't > mean that. I meant the viewer is fooled into thinking the world can see their files - at the time there was stories that said it did. A bit like the story that mobile phones cause explosions - if 15 million idiots believe a stupid thing - it's still stupid. But if 5 journalist repeat it.... :-( > > No objection to the default setting. My complaint is that the instructions > in Mozillazine Security Policy are not working. Check and correct. Otherwise people may cease to RTFM :-D <snipped> > >> The following works on my machines - no modification of browsers required:- > > That is your own Category2.html file? You get the link from my primary page > or your's? If the second case, where does it reside? It's my creation (but you welcome to it!) - both Category2.html and Category3.html reside in the same location. I did try numerous variations in an attempt to see your perspective. > > Thanks, ... Peter E. > > Cheers -- We all pay for life with death, so everything in between should be free. ~ Bill Hicks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df9d24c.2030...@gmail.com
