[quote user="bfluet"]If double clicked I receive the IER warning but the file does not open.[/quote]

Brian, Pegasus Mail actually executes resp. loads these files and expects to see real spaces instead of encoded ones. I've now added a conversion check so it should work as expected. If you send me an email (via IERs About dialog) refering to this thread I can send you a test version.

I am trying to send a link to a file to my users.  I have created a hyperlink that generates the link "FILE://\\SERVER01\SHARED\VENDOR LIST.PDF" but the file doesn't open when the link is clicked.  When tested with BearHTML instead of IERender I see "protocol refused: file" displayed in the bottom left corner of the message window.  I did this more out of curiosity than anything else since it would be a mute point if it worked with BearHTML.  Anyone know why a link to a file doesn't work and/or how to get one to work?

Brian    As far as I know File: protocol requires forward slashes ie file:/// before the actual file location and of course the directory delimiters should be forward slashes too.  See http://en.wikipedia.org/wiki/File_URI_scheme.  In your case there is the SERVER01 between // and / so your Url would

be File://server01/ SHARED/VENDOR LIST.PDF   P.S Some parsers only allow file:/// at the start of the Url which signifies that the wanted file must be accessible on the webserver

Martin 

I have tried forward slashes, back slashes, two and three slashes and escape codes. I can get to resulting hyperlink to look exactly like what works in Word but the pdf viewer isn't invoked nor is the file opened.

What does the "protocol refused: file" indicate when BearHTML is active?  Not sure it exactly said "protocol refused", might have been "protocol blocked" or something like that.

Second point above.  This is a security feature in Bear that does not allow remote access to things like a C drive on a remote web server. Only hypertext protocols are allowed. Things like Callto and Skype invoke applications on the Pegasus Mail machine (ie email message recipient machine.)

So the question is, do you want email message readers to be able to fetch files from a remote location, even if it is just as in your case, another server in your server pool?  The security issue would then be that accessing another device within your organization *MIGHT* be ok, as the email recipient will have logged into the company servers before. But would you want external email users accessing your server files through a request from a clickable link in the email message?.

Martin 

In my case it would be ok since there is no outside access to our servers and permissions limit what users can access but I certainly see your point. 

So it should be enabled by an option setting perhaps?

Martin 

I see a value in being able to send file links to local users. 

If there is an option in BearHTML would there also need to be one in IERenderer?

[quote user="bfluet"]If there is an option in BearHTML would there also need to be one in IERenderer? [/quote]

IER already allows access to local files with URLs like this one "file://C:\Windows\SysWOW64\scrnsave.scr" (an existing file on W7-64 systems): You'll get warnings for certain file types, though.

The filename of my target document contained spaces.  I was using the escape code (%20) for the spaces in my test URLs but they were resulting in an invalid path.  I got it to work once I removed the spaces.  It works only with IERenderer active and only after acknowledging a warning. 

Martin, if a similar required warning acknowledgement is a possibility in Bear I think that would be a better option than an on/off configuration switch.

The way to solve the spaces problem is to change them to underscores, then the filename is quite readable.

I will work on the warning dialog over the next little while. I will have to get some tranalations done, unless I can borrow from Michael.

Martin 

[quote user="irelam"]The way to solve the spaces problem is to change them to underscores, then the filename is quite readable.[/quote]

Just when you stop thinking about DOS...

[quote user="irelam"]I will work on the warning dialog over the next little while. I will have to get some tranalations done, unless I can borrow from Michael.[/quote]

Thanks Martin!

[quote user="irelam"]I will work on the warning dialog over the next little while. I will have to get some tranalations done, unless I can borrow from Michael.[/quote]

Since my resources are delivered via IER's HTML help files this should be easy enough.

[quote user="bfluet"]The filename of my target document contained spaces.  I was using the escape code (%20) for the spaces in my test URLs but they were resulting in an invalid path.[/quote]

I never tested blanks with non-text files: Files to be opened in a browser window (plain text, HTML - tested with Opera, Firefox and IE) will open properly if containing encoded spaces.

Interesting.  My file was a pdf file which would not open with encoded spaces but opened fine when the spaces were replaced with underscores.  IIRC, IER would detect an invalid path when the filename contained encoded spaces.

[quote user="bfluet"]IIRC, IER would detect an invalid path when the filename contained encoded spaces. [/quote]

Does IE itself do so as well?

I might have been mistaken about the invalid path.  I just retested using

file://p:/shared/vendor%20list.pdf

and

file://///server01/userfiles/shared/vendor%20list.pdf

In both cases:

If double clicked I receive the IER warning but the file does not open.

If "open in browser" is selected then the File download window opens in the browser as expected (both IE and FF). 

[quote user="bfluet"]In both cases: If double clicked I receive the IER warning but the file does not open.[/quote]

I may be able to fix this.

Michael,

   I don't understand the Url workings. To my understanding the c:\windows is illegal, as the first parameter after the protocol ftp:// is the domain and the second is the path to the required file. The colon character is reserved according to the RFC in either domain or path parts of the Url.   This would mean that the c: is being interpreted as the domain. the Url above would then appear to be corrected as:  file://c/windows/syswow64/scrnsave.scr 

Martin 

[quote user="irelam"]I don't understand the Url workings. To my understanding the c:\windows is illegal, as the first parameter after the protocol ftp:// is the domain and the second is the path to the required file. The colon character is reserved according to the RFC in either domain or path parts of the Url.[/quote]

Martin, I don't really care about RFCs or rules in this case since all browsers I usually test (IE, Firefox and Opera) firstly can deal with either one and secondly automatically convert such URLs to different versions of your correct URL (Firefox creates file:///C:/Windows/SysWOW64/scrnsave.scr while IE even uses a plain file path, i.e. simply C:\Windows\SysWOW64\scrnsave.scr (you can see it only for a second or so)). IOW: If they don't care why should I? I just make sure everything works properly with each browser I test. And furthermore: I didn't want to present a correct URL, I just stated that it works for the purpose discussed in this thread.