file:: , https:: dont resolve

2006-01-19
2013-04-17
  • In a page with text links like:

    [file:///shares/doc/Product_Catalogue.pdf]
    [https://mail.mywork.com]

    they appear as links but dont pop up the doc or tool
    instead they go to:

    http://sunir.org/apps/meta.pl?https%3A%2F%2Fmail.mywork.com

    What is going on...?

     
    • Andy Fundinger
      Andy Fundinger
      2006-01-19

      standard links should not be enclosed in square brackets, there is code to automatically detect it.   Square brackets can be used with links if you want to title them, but just simple and plain should not need them.

       
      • Square brackets or not - doesnt make any difference - the same happens.

        However I note the response from Milky. This has given me food for thought

         
    • Mario Salzer
      Mario Salzer
      2006-01-19

      file:// and https:// are registered protocol prefixes, so I'm unsure why it tries to treat them as pagenames. You however seem to have enabled one of the linking/ plugins, which redirect to the MetaWiki search for non-existant pages. Try disabling "selfmetawiki.php" and "interwiki/metawiki.php" or others.

       
      • Milky,

        Thanks for the pointer.
        *Mostly* fixed. Please read on..

        The problem was that:
             include(plugins/mpi/mpi.php)
        was pulling in a plugin that caused the incorrect action on http:// and https:// links.

        I fixed this with:
             define(EWIKI_MPI_DEMANDLOAD, 0);

        and adding in the includes that I needed.

        Now http:// and https:// work correctly but I still cant get file:// to do *anything*.

        If I have something like:

           file://shares/doc/mydoc.pdf

        or

           ["mypdf doc" file://shares/doc/mydoc.pdf]

        when I click on it *NOTHING* happens. Is there some way I can see what is going on behind the scenes or any pointers you can give as to this problem?

        Cheers

        Paul

         
        • Mario Salzer
          Mario Salzer
          2006-01-20

          Did you find out which of the mpi plugins mangled the URLs? (Normally only the ones mentioned in a <?plugin> part engage.)

          I'm not sure that we have any such plugin which targets file:// URLs specifically. But you could try to give this URL scheme precedence in the Wiki formatting kernel. Search for '$ewiki_config["idf"]["url"]' in the core script and move "file://" forward (to the start of that config array).

          But if the page source contains the "file://" prefix as-is, then there could be a user agent problem. Also try to write three slashes in the page source (like in "file:///share/..."), because there MAY appear hostnames for file:// URLs, too. (useless, but I think that's allowed in the according spec for symmetry with http://\)

           
          • Hi,

            Fiddling around with $ewiki_config has achieved anything.

            file:// | ///  does not do anything when run from inside the ewiki.php

            However if I save the generated page source off as say ~/mypage.html then open it directly it works as expected.

            So I can see that it is some interaction of the ewiki code/wrapping that is causing the fail, but what?

            Any Ideas how I debug this.

             
            • Milky,

              forgot to say other than this "teething" issue it is a very good tool.

              Good stuff.

               
              • Andy Fundinger
                Andy Fundinger
                2006-01-26

                It is always very nice to hear that in the middle of a thread like this :-)

                 
    • Ok I know a little more now, but am still non the less confused.

      For some reason adding in:

      include("plugins/mpi/mpi.php");                

      causes http::, https:: , file:: to get redirected to 
      http://sunir.org.....

      I have no idea why.

      (which I was using for <?plugin SetTitle ...> & TableEditor)

      However without this:
      http:// and https:// work correctly, but
      file:// does not do anything

      Ideas please. It shte file:// option that I really need to get working

      Thanks

       
    • Roland
      Roland
      2006-01-25

      Local 'file:/' links within HTML pages
      definitely DO NOT work in firefox/mozilla etc.
      Please see:
      http://kb.mozillazine.org/Links_to_local_pages_don't_work

      /Roland/

       
      • ?Confused?
        Your link doesnt resolve... that might help in the solution?

        file:// does work in firefox & mozilla etc. We do it all the time... in normal pages that is.

        My problem is file:// does not work from within the ewiki php

        eg:
          http://myewiki/home.php?page=SandBox

        has the php generated code

        <p><a href="file:///shares/eda/doc/Catalogue.pdf">file:///shares/eda/doc/Catalogue.pdf</a>
        </p>

        This does not do *ANYTHING*

        However if I save the page source to say ~/testpage.html

        then load that code directly (not using ewiki). then the link resolves.

        So it has to be something to do with the ewiki php, but I dont know what. nor how to debug

         
        • Mario Salzer
          Mario Salzer
          2006-01-26

          This is getting stranger and stranger... But I'd say this is entirely a quirk within Firefox.

          If there is the ABSOLUTE ftp:///-URL in the generated HTML pages source, then browsers are required to not interpret it differently. It is possible that there's something in the <head> section (e.g. <base href="...">) that influences your browser - but it would still be a browser bug if this was the case.

          You could try to embed something like <base href="http://myewiki/"> into your layout/index.php script - or for further testing remove it if something is there.

          Otherwise please post the HTTP headers here that ewiki normally sends with its pages:

             wget -S http://myewiki/home.php?page=SandBox

          (Though I don't believe there is anything in it, which could really affect your browser with this.)

          But after all, if the link hrefs start with "file:///" in the HTML source, there shouldn't be any problems ever. So please also give your setup a try in a different browser.

          Best,
          mario

           
      • Mario Salzer
        Mario Salzer
        2006-01-26

        Oooops, should have read that earlier; but didn't see your comment in my sf.net mail inbox..

        http://kb.mozillazine.org/links_to_local_pages_don't_work

        This clears up everything up quite a lot! (and the Mozilla behaviour probably makes sense security-wise, tohugh I think file:// still works as-is in my non-JS and textmode-only browsers like w3m/links)

        Many thanks for your time with looking it up and helping us to clear that problem, roland!

         
        • Guys.

          You've solved it.

          Many thanks. :-)

          Cheers

           
    • ***SUMMARY**
      ***********************************

      Just in case anyone else stumbles over this...

      I had 2 problems.

      The first was that all links were redirected to some *odd* (its coded in the ewiki.php so its not that obscure). This (thanks Milky) I discovered was due to something odd in the MPI plugins. Admittedly I have not worked out which, but then I dont mind too much now as the users on our site are happy again.

      The second was hiddden beind the first in that file:// did not do anything. This turns out to be  a result of Mozilla/Firefox being a bit, to my mind, *too* careful about what it allows you to do. Since we publish our ewiki as an alias http address (not as the home site http::/interanet.mycompany.home/index.html, but as    
      http::/ewiki.mycompany.home/) it was assuming that this was an external site and stopping (very quietly) file:// from doing anything.
      Many thanks to Roland for pointing that out - the link he point at does resolve (take care with the ' in the middle) and has a very thorough explanation and soln. Which I have now implemented site wide.

      So finally - many thanks to Milky and Roland for sorting this out and keep up the good ewiki.

      Cheers

      Paul