I have a hyperlink control that inside a GridView1. Its navigation URL is set to be
C:\PdfDirectory\2014-0001-100.pdf . However, when I want click it, the file is not opened but instead a new tab opened with a message :The address wasn't understood. When I mouse over the hyperlink, it shows me the same path "C:\PdfDirectory\2014-0001-100.pdf".
The file is available on the exact place and I can open it manually. So why I get this problem? Why it can't understand this local directory file?
The Hyperlink part of the aspx file is as following:
Most if not all browsers should now block referencing a local client side file from an internet web page for safety reasons. You can't just place this file on your web server as it seems you expect to find the same file on all of your machines anyway ?
Theorically and as it seems your app is used on tightly controlled machines you could perhaps unblock this but my personal preference would be to really avoid this kind of client side configuration even in a controlled environment.
Or is this just some kind of misunderstanding about how referencing a server side file works ? You must always use a url as in particular even if it could theorically seems to work for you (when using a machine which is both the client and the web server) for
real users C: will be their own C: local drive rather than the web server side C: drive.
Thanks alot PatriceSc for your exaplanation. However I still don't know what to do. How people can create local temporary folder to open it, if there is no chance as most of browsers blocks a local side file.
Do you mean that the only way is to read it from a directory in the server?
Who creates this file ? If this is on the server side keep in mind that it would written on the web server C: drive which is anyway not availble to the client side. You would rather stream the file to the browser so that the user can save or open it.
In short if you want to read a client side file the user must explicitly select this file so that it is uploaded to the web server and a file generated on the web server side must be downloaded to the browser and explicitly accepted by the user.
I believe this file is created on the server side and that there is some confusion about what happens on the client side (HTML, CSS, JavaScript in your browser) and what happens on the server side (all your C# code) which is often seen when you start to
develop for the web as you are often in the very special case where the browser client side and the web server side is the same machine.
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue.
If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
Yes but before showing an example I woud like to understand what you are trying do to ?
I'm not sure who is creating this client side temporary file. In this case you could use a upload dialog, the user will have to select this file and then you can show this content (a browser is not allowed to access a client side file is not explicitely
allowed by a user by selecting this file).
I suspect that maybe this file is created by your server side C# code in which case a real web server would write it to its server side C: drive rather than to the client side C: drive. Then you would need to use a http link to this file or maybe to Stream
it to the browser if you want to allow the user to save this on its hard drive (once again the user have full control on what happens).
Or if something else we would need to know what you are trying to do. For now we are seeing a solution which seems wrong but we are not sure about what exactly you are trying to solve...
I have document management system. The user upload files then refer back to these files.
The uploading is perfectly done. The problem is that when the user want to open back these files, I copy the file that he already uploaded on past into a local folder to avoid any security problem. Then opening this local file opened by hyperlink.
I can not let the user read directly from the server. If this made, the user may type the url of his colleague manually in the website address location, which can enable him to view other's contents, which violate the privacy
I have document management system. The user upload files then refer back to these files.
The uploading is perfectly done. The problem is that when the user want to open back these files, I copy the file that he already uploaded on past into a local folder to avoid any security problem. Then opening this local file opened by hyperlink.
I can not let the user read directly from the server. If this made, the user may type the url of his colleague manually in the website address location, which can enable him to view other's contents, which violate the privacy
Unfortunately, you are discovering an error in the original design during the implementation phase. You'll need to rethink the design or look into products that already have these features like SharePoint.
Member
56 Points
657 Posts
Very stange problem: The address wasn’t understood
Oct 19, 2017 04:39 PM|alihusain_77|LINK
I have a hyperlink control that inside a GridView1. Its navigation URL is set to be C:\PdfDirectory\2014-0001-100.pdf . However, when I want click it, the file is not opened but instead a new tab opened with a message :The address wasn't understood. When I mouse over the hyperlink, it shows me the same path "C:\PdfDirectory\2014-0001-100.pdf". The file is available on the exact place and I can open it manually. So why I get this problem? Why it can't understand this local directory file?
The Hyperlink part of the aspx file is as following:
<asp:TemplateField HeaderText="الرابط"> <ItemTemplate> <asp:HyperLink ID="AttachmentLink" runat="server" Target="_blank" ImageUrl="~/Images/Attachment1.png" CssClass="HyperLinkStyle"> </asp:HyperLink> </ItemTemplate> <ItemStyle BorderWidth="1px" Width="3%" HorizontalAlign="Center" /> </asp:TemplateField>I will highly appreciate your help with thanks
All-Star
45560 Points
16518 Posts
Re: Very stange problem: The address wasn’t understood
Oct 19, 2017 04:56 PM|PatriceSc|LINK
Hi,
You could try with the file protocol shown at https://msdn.microsoft.com/en-us/library/aa767731(v=vs.85).aspx but it likely won't work anyway.
Most if not all browsers should now block referencing a local client side file from an internet web page for safety reasons. You can't just place this file on your web server as it seems you expect to find the same file on all of your machines anyway ?
Theorically and as it seems your app is used on tightly controlled machines you could perhaps unblock this but my personal preference would be to really avoid this kind of client side configuration even in a controlled environment.
Or is this just some kind of misunderstanding about how referencing a server side file works ? You must always use a url as in particular even if it could theorically seems to work for you (when using a machine which is both the client and the web server) for real users C: will be their own C: local drive rather than the web server side C: drive.
Member
56 Points
657 Posts
Re: Very stange problem: The address wasn’t understood
Oct 19, 2017 06:34 PM|alihusain_77|LINK
Do you mean that the only way is to read it from a directory in the server?
Member
56 Points
657 Posts
Re: Very stange problem: The address wasn’t understood
Oct 19, 2017 08:01 PM|alihusain_77|LINK
I added the file:/// to the navigation but the problem is still appearing. PLEASE advise me.
All-Star
45560 Points
16518 Posts
Re: Very stange problem: The address wasn’t understood
Oct 19, 2017 08:07 PM|PatriceSc|LINK
Who creates this file ? If this is on the server side keep in mind that it would written on the web server C: drive which is anyway not availble to the client side. You would rather stream the file to the browser so that the user can save or open it.
In short if you want to read a client side file the user must explicitly select this file so that it is uploaded to the web server and a file generated on the web server side must be downloaded to the browser and explicitly accepted by the user.
I believe this file is created on the server side and that there is some confusion about what happens on the client side (HTML, CSS, JavaScript in your browser) and what happens on the server side (all your C# code) which is often seen when you start to develop for the web as you are often in the very special case where the browser client side and the web server side is the same machine.
Member
56 Points
657 Posts
Re: Very stange problem: The address wasn’t understood
Oct 19, 2017 09:27 PM|alihusain_77|LINK
Would you please show me example of the solution you suggest. I will highly appreciate that Mr. Patrice
Contributor
2250 Points
815 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 09:46 AM|Billy Liu|LINK
Hi alihusain_77,
Do you want download the pdf file by click the HyperLink?
I think your problem is caused by browser security setting.
You could try to use a linkbutton, when user click the linkbutton, you could download the file in onclick event:
For example:
In aspx:
In behind code:
protected void LinkButton1_Click(object sender, EventArgs e) { Response.ContentType = "Application/pdf"; Response.AppendHeader("Content-Disposition", "attachment; filename=Hello.pdf"); Response.TransmitFile(Server.MapPath("~/Doc/Hello.pdf")); Response.End(); }Best Regards,
Billy
Please remember to click "Mark as Answer" the responses that resolved your issue.
If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
Member
56 Points
657 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 11:21 AM|alihusain_77|LINK
Thanks Mr. Billy.
What you shown is a link to server file, but what I need is link to local temporary file which its path: C:\Users\Ali\AppData\Local\Temp\Testing.txt
All-Star
42631 Points
18122 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 11:29 AM|mgebhard|LINK
The browser does not allow a web server to retrieve a file from the client's machine. You'll need to rethink the design.
All-Star
45560 Points
16518 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 11:43 AM|PatriceSc|LINK
Yes but before showing an example I woud like to understand what you are trying do to ?
I'm not sure who is creating this client side temporary file. In this case you could use a upload dialog, the user will have to select this file and then you can show this content (a browser is not allowed to access a client side file is not explicitely allowed by a user by selecting this file).
I suspect that maybe this file is created by your server side C# code in which case a real web server would write it to its server side C: drive rather than to the client side C: drive. Then you would need to use a http link to this file or maybe to Stream it to the browser if you want to allow the user to save this on its hard drive (once again the user have full control on what happens).
Or if something else we would need to know what you are trying to do. For now we are seeing a solution which seems wrong but we are not sure about what exactly you are trying to solve...
Member
56 Points
657 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 01:28 PM|alihusain_77|LINK
I have document management system. The user upload files then refer back to these files.
The uploading is perfectly done. The problem is that when the user want to open back these files, I copy the file that he already uploaded on past into a local folder to avoid any security problem. Then opening this local file opened by hyperlink.
I can not let the user read directly from the server. If this made, the user may type the url of his colleague manually in the website address location, which can enable him to view other's contents, which violate the privacy
All-Star
42631 Points
18122 Posts
Re: Very stange problem: The address wasn’t understood
Oct 20, 2017 02:01 PM|mgebhard|LINK
Unfortunately, you are discovering an error in the original design during the implementation phase. You'll need to rethink the design or look into products that already have these features like SharePoint.