I'm just started web developing not long ago, and I'm wondering why running HTML on my computer comes up with file:/// and then the file path and name in the browser url bar. For example, what I'm testing right now is:
file:///D:/WebDesign/HTML/test/default.html
Why isn't it file://, or just the pathname?
Is there a certain reason for this?
thanks for any answers.
// is part of the general format of URI schemes.
The next / comes after the optional — if defaults to localhost — hostname (since you can have a network path for file URIs).
See the Wikipedia article for more details.
It is a standard URL code for a local file. Also Check out this:-
the slash is a general, system-independent way of separating the
parts, and in a particular host system it might be used as such in a
pathname (as in Unix systems) or internally mapped to another
character
That is just standard URL code for a local file. A similar syntax is used to refer to a file on a network drive.
However, if you are attempting to develop like that you will run into problems, especially if you intend to test server-side functionality in languages like PHP. You may wish to look into installing a (free) program such as XAMPP or WAMP/MAMP that will emulate an apache server and allow you to test these things.
You can find some very helpful (free) tutorial videos here
Look at the first three videos here
And here's another that discusses installing XAMPP/WAMP
Related
Why can't a local page like
file:///C:/index.html
Send a request for a resource
file:///C:/data.json
This is prevented because it's a cross origin request, but in what way is that cross origin? I don't understand why this is a vulnerability / prevented. It just seems like a massive pain when I want to whip up a quick utility for something in JavaScript/HTML and I can't run it without uploading to to a server somewhere because of this seemingly arbitrary restriction.
HTML files are expected to be "safe". Tricking people into saving an HTML document to their hard drive and then opening it is not difficult (Here, just open the HTML file attached to this email would cause many email clients to automatically safe it to a tmp directory and open it in the default application).
If JavaScript in that file had permission to read any file on the disk, then users would be extremely vulnerable.
It's the same reason that software like Microsoft Word prompts before allowing macros to run.
It protects you from malicious HTML files reading from your hard drive.
On a real server, you are (hopefully) not serving arbitrary files, but on your local machine, you could very easily trick users into loading whatever you want.
Browsers are set up with security measures to make sure that ordinary users won't be at increased risk. Imagine that I'm a malicious website and I have you download something to your filesystem that looks, to you, like a regular website. Imagine that downloaded HTML can access other parts of your file system and then send that data to me through AJAX or perhaps another piece of executable code on the filesystem that came with this package. To a regular user this might look like a regular website that just "opened up a little weird but I still got it to work." If the browser prevents that, they're safer.
It's possible to turn these flags off (as in here: How to launch html using Chrome at "--allow-file-access-from-files" mode?), but that's more for knowledgeable users ("power users"), and probably comes with some kind of warning about how your browsing session isn't secure.
For the kind of scenarios you're talking about, you should be able to spin up a local HTTP server of some sort - perhaps using Python, Ruby, or node.js (I imagine node.js would be an attractive option for testing javascript base apps).
On an intranet site, let's say I want to link to a file on a share using UNC, at:
\\servername\foldername\filename.rtf
It seems the correct way to do this is with markup like this:
filename.rtf
That's five slashes - two for the protocol, one to indicate the root of the file system, then two more to indicate the start of the server name.
This works fine in IE7, but in Firefox 3.6 it will only work if the html is from a local file. I can't get it to work when the file comes from a web server. The link is "dead" - clicking on it does nothing.
Is there a workaround for this in Firefox? Those two browsers should be all I need to worry about for now.
Since this is obviously a feature of Firefox, not a bug, can someone explain what the benefit is to preventing this type of link?
This question has been asked at least twice before, but I was unable to find those posts before posting my own (sorry):
Open a direct file on the hard drive from firefox (file:///)
Firefox Links to local or network pages do not work
Here is a summary of answers from all three posts:
Use WebDAV — this is the best solution for me, although much more involved than I had anticipated.
Use http:// instead of file:///// — this will serve up a copy of the document that the user cannot edit and save.
Edit user.js on the client as described here — this worked for me in Firefox 3.6.15, but without access to client machines, it's not a solution.
In Firefox, use about:config, change the Security.fileuri.strict_origin_policy setting to false — this doesn't work for me in 3.6.15. Other users on [SO] have also reported that it doesn't work.
Use the locallinks Firefox extension — this sets the Security.fileuri.strict_origin_policy to true for you, and appears to have no other effect.
Read the file server-side and send it as the response — this presents the same problem as simply configuring your web server to use http://.
Browsers like Firefox refuse to open the file:// link when the parent HTML page itself is served using a different protocol like http://.
Your best bet is to configure your webserver to provide the network mapped file as a web resource so that it can be accessed by http:// from the same server instead of by file://.
Since it's unclear which webserver you're using, I can't go in detail as to how to achieve this.
In Firefox to Open File:\\\\\yourFileServer\docs\doc.txt for example you need to turn on some options in Firefox configuration:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://yourServer1.companyname.com http://yourServer2.companyname.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
As it turns out, I was unaware that Firefox had this limitation/feature. I can sympathize with the feature, as it prevents a user from unwittingly accessing the local file system. Fortunately, there are useful alternatives that can provide a similar user experience while sticking to the HTTP protocol.
One alternative to accessing content via UNC paths is to publish your content using the WebDAV protocol. Some content managements systems, such as MS SharePoint, use WebDAV to provide access to documents and pages. As far as the end-user experience is concerned, it looks and feels just like accessing network files with a UNC path; however, all file interactions are performed over HTTP.
It might require a modest change in your file access philosophy, so I suggest you read about the WebDAV protocol, configuration, and permission management as it relates to your specific server technology.
Here are a few links that may be helpful if you are interested in learning more about configuring and using WebDAV on a few leading HTTP servers:
Apache Module mod_dav
IIS 7.0 WebDAV Extension
Configuring WebDAV Server in IIS 7, 6, 5
Add your own policy, open configuration "about:config" in the location bar and add three new entries:
capability.policy.policynames MyPolicy
capability.policy.MyPolicy.sites http://localhost
capability.policy.MyPolicy.checkloaduri.enabled allAccess
Replace http://localhost with your website.
Works with Firefox 70.0.
I don't know if this will work, but give it a shot! Old article, but potentially still useful.
http://www.techlifeweb.com/firefox/2006/07/how-to-open-file-links-in-firefox-15.html
Found an interesting article about "Cruftless" links (removing the "index.html" from links) but when I do that no browser shows the local pages.
http://www.nimblehost.com/blog/2012/11/why-cruftless-links-are-better/,
This is understandable, it's a 'file' url from a local machine, so what do people do to work on basic html sites offline? How do they preview them?
For example, no browser (understandably) will display this...
file:///JOBS/ABC/About/
... but this is fine...
file:///JOBS/ABC/About/index.html
?... so what do people do to get around this?
The meaning of file: URLs is, by definition, system-dependent. Normally browsers map them to files in the file system in a relatively straightforward manner.
Thus, a link with href value like file:///JOBS/ABC/About/ may or may not work, depending on system. It may fail, or it may open a generated document containing a directory (folder) listing, or it might do something else.
There is normally no need to get around this, and it is pointless to worry about SEO when dealing with local files.
This could, however, matter during site development when you work with a site locally (and perhaps test and demonstrate it locally). Then you might wish to have, say, About us so that it works locally as well as on a server, yielding About/index.html in both cases but without hard-wiring index.html in HTML markup.
I’m afraid the answer is “you can’t”. But as a workaound, you can install and use a local HTTP server, with settings similar to those that you will have on the real server. This means a little extra work (mainly downloading and installing and configuring software like XAMPP), but it also gives you important other benefits, like testing your pages locally with server-based features (to the extent that the real server is similar to the local server).
The user, when he clicks a link, needs to get my compressed html file that his browser will uncompress automatically, without any fuss. What must I do on the server side to accomplish this?
Thanks!
-- ben
I see now from your comment that you're literally trying to get compressed file to open transparently in a browser, not just compress the whole HTTP response.
That is definitely an issue for ServerFault. It relies on two things:
The configuration of your HTTP server (it must be able to determine the appropriate MIME type and tell it to the browser, for most browsers the filename alone is not sufficient).
The browser itself. There's no requirement that browsers be able to transparently open such a file, though many will if given the proper MIME type information.
(Original answer below)
I almost said this belongs on Server Fault, but I think the answer is needed on SO because it's not obvious it belongs on SF unless you understand the mechanisms at work, so:
In most cases, compressing HTTP responses is a capability of web servers, and you or your sysadmin will need to configure the web server (e.g. Apache with mod_deflate) to use that capability.
In the event that your application is its own web server, you need to review RFC 2616 (the HTTP/1.1 spec) and/or the documentation for any framework you're using.
I'm not exactly sure what the right thing is if you're using the webserver like as a reverse proxy... Probably still needs to be in the webserver, if it's possible at all.
What server are you running?
If you have Apache, you can set up mod_deflate
I have an application that people use through Remote Desktop/Terminal Server. The application supports digital signatures. Well, the digital signature pad is on the client, but the program runs on the server. The signature pad also does not support being shared as a device through Remote Desktop(not listed with "Supported Plug And Play Devices" in local resources).
What is the best way of being able to send the signature to the server from the client machine? Preferably with having the least amount of setup for the users(there are a lot of clients and a fair amount of servers this must be done for)
My best idea so far is sharing the clipboard and using it to send messages from server to client(with the client application "polling" the clipboard for a special clipboard format) I feel like this may not be very fast or stable though as I don't think Remote Desktop was designed for it.
Also, we are open to [reasonable] language choices like C/C++, C#, Delphi(the application is written in this), etc. Also, the signature pad is a Topaz TS460(connects by USB).
Can anyone give me ideas on how this can be done or if the clipboard idea of mine is probably the best?
tl;dr: What is the best way of sending an image from a client to a server through remote desktop?
Update:
Well, I've done a bit of testing with plain ASCII text(I can't get files to transfer) and it seems that there is problems copying large amounts of text. I tried copying 43M of text and after a long period of waiting I just got an empty clipboard(Like it did a paste, but there was no text pasted) I was able to transfer about 2M of data though (at decent speeds) between server and client, so this may be feasible for signature images(which will be either jpeg or png compressed)
Have you looked into using Remote Desktop Virtual Channels? http://msdn.microsoft.com/en-us/library/aa383509(VS.85).aspx
for topaz signature pad and credit card swiper you will need the serial type. It will work, already tried it. but I guess this question is too old for me to answer. Does IPAD as well as well as other tablets work on terminal and citrix setup?
I have not tried with Remote Desktop, but one thing that comes to mind is installing a good macro tool on the client. AutoHotKey ( http://www.autohotkey.com/ ) is a free tool that lets you create runable scripts that can do things like open applications and send key strokes to them.
I'm not sure how well it would work with remote desktop, but I know for certain that you can easily setup a script that would launch an application, send it "key strokes" to generate data, copy the data to the clipboard, switch to another application and then paste in the data.
When AutoHotKey is installed, you have the option of associating the file types of the scripts with the app so that end users could just double click your scripts desktop icon to run it. No command line messyness for them.
If all you need to do is transfer an amount of data (a file) from the client to the server it is fairly easy. Polling for a file seems also more logical as polling via the clipboard.
When you connect the client should enable sharing a harddisk (at least one). You can specify the options every time you connect, or you can send the client a .RDP file that is preconfigured.
If you can get the user to put the file on a fixed position, you can access the file C:\Shared \File.jpg using a path like \tsclient\c\Shared\File.jpg.
Here's an explanation (with nice screenshot) how to copy files with Remote Desktop:
http://www.jakeludington.com/ask_jake/20051218_copying_files_with_remote_desktop.html
I wasn't sure if your question rules already out this approach or not.