PDF links (7.11.2.2) and behavior on the web

Question

Hello all,
I'm trying to generate a PDF file (from scratch, using a C++ library - but that's not relevant to my question) that uses links to specify the location of linked files relative to the root of a drive - NOT relative to the PDF file itself (i.e.  I don't want to use ../../).
As best I can tell from the PDF specification (PDF32000_2008.pdf, section 7.11.2.2 and 7.11.2.3) - creating such links should be as simple as using a double forward slash to specify 'no drive'.
e.g.   To link to the file in c:\images\test.jpg from a PDF file you know is also on the c: drive - the links written form is: //images/test.jpg (as per table 43)
This works fine when I access it from my desktop - when both the PDF and JPG are on my c: drive - however if I copy the PDF to my test web server, and put the test.jpg file in a folder called images on the root of my web server - the link fails when executed in the PDF opened on the server (in the Reader loaded inside the browser).
I can see what's happening - and want to know if there is something I can do (or should be doing) to fix it.
What happens is that the 'no drive' path is actually removing too much from the path.
Instead of trying to open http://127.0.0.1/images/test.jpg, the actual link that appears in the browser address bar is http://images/test.jpg.
Any help would be much appreciated,
Thanks
Adam
(I've attached a example.pdf file that contains a link to \images\test.jpg - which works on the desktop, but not in the browser)

Answer 1

Hi Leonard,
First off, thanks a lot for escalating this to the engineering team.  I didn't expect that from a free open forum.  - I'm impressed.
Of course, the engineer is right - I didn't mention it because I was secretly hoping that there would be a solution that worked for both - given the portable nature of a PDF.  (I'm still befuddled as to why a root relative file path is processed the way that it is in the context of a web browser - I expected it to be relative to the root of the site)
I guess, assuming it's possible to detect whether the PDF was opened in a standalone reader vs a browser using Acrobat JavaScript - I could generate link hotspots for both scenarios at publish time - defaulting one set to hidden (or back) - and then switch them when the PDF is loaded using script again. I'm not sure whether any of that will trip a security warning in the default configuration - but don't think so as we already use JavaScript to do multi-link menus.
If nothing else, at least I know it isn't going to work the way it is (so won't keep trying to jiggle things) - and have some ideas on workarounds.
Thanks for all your help,
Adam