My goal is to set the background image from a local image on my computer.
I have two lines of code, one that works and one that doesn't:
(the local one does not work)
_html.style.backgroundImage = 'url("urlsourceblahblahblah")';
_html.style.backgroundImage = 'url("/~/Content/images/Image1.jpg")';
When I try running the second one (the local one), this is the error that I get:
GET http://localhost:23433/~/Content/images/Image1.jpg 404 (Not Found)
I can verify that the image path is correct, even if I put the image file in the same directory to make things simple. I know from documentation that the backgroundImage property in JS requires url(). Is there any reason why this wouldn't work?
This is a tricky one... I can think of some problems this can have:
The server doesn't know what ~ refers to (are you running windows?)
The user running the server is not the same as the one you are logged in as. (~ stands for home directory, and when server evaluates it'll lead to user running the server home directory).
The server is configured to ignore every request which is above it's www / html / localweb folder. (Altough in this case it would be weird to reply with a 404, a 403 would make more sense)
By the way, this is only possible if the server and the client are on the same machine. I don't know why you want it, but if you pretend to upload a website and have its background set to some field on the client machine, then simply forget about it.
The ~ abbreviation for your home directory is not recognized by the browser. However, expanding it will only help if the image is in a directory that is being served on local host. I don't know what you are using for a web server, but you'll need to find out what directory it is expecting to serve as its root
You can't refer to an image from the users machine. The browser does not have access to the users file system, otherwise, any website you visit would be able to access your "Pictures" folder for example.
The image you use needs to be in your website directory or another public url. If you need to use a picture from the users machine, then you should do so with a file uploader.
Related
I have an HTML based project that works with media from other websites, which embeds images / songs / videos using their direct links. The system works perfectly so far, but I wish to make a change: As a lot of assets are accessed repeatedly by viewers, it would seem more optimal to cache them in a controlled way, so whenever certain media pops up you don't need to fetch it from the origin server each time. I never did this before so I don't know if and how it can be done.
To use an oversimplification: I have an embedded photo called "image.png" inside an image element, which will show up whenever I open the site. Currently it's simply defined as:
<img scr="https://foo.bar/image.png">
Works perfectly! However I want to make sure that when my site is accessed, you don't need to fetch that image from foo.bar each time: You will keep it in a local directory after downloading it once, from which the script can fetch and work with the file independently. For Firefox for instance, this subdirectory would be inside your ~/.mozilla/firefox/my_profile directory. Ideally it can be defined using a fixed name, so no matter which URL the website is opened from it uses the same cache path instead of each mirror of the project generating its own.
First, my script must tell the browser to download https://foo.bar/image.png and store it into this cache subdirectory. After that, it would need to generate a link to embed it directly from that subdirectory, so the URL I use would now be something of the following form:
<img scr="file://path_to_cache/image.png">
How do I do those two things, in a way that's compatible across popular web browsers? As a bonus, it would be useful to know if I can limit the size of this cache directory, so once it reaches say 100 MB the oldest items will be removed to stay under that size.
You could alternately add caching to your server's .htaccess file.
This site explains how: https://www.siteground.com/kb/leverage-browser-caching/
However this does not cache the image on the user's machine, it is cached on the server for quicker response.
You could use service workers to cache images on the user's machine.
https://developers.google.com/web/ilt/pwa/lab-caching-files-with-service-worker
Hope this helps.
I have a web application that triggers actions at the server side which result in the generation of data files.
The so generated data files are stored within a folder at drive different from the one where the Web application is.
What I tried so far is to create a shortcut (Windows Server) next to the Index.html, where the shortcut points to the folder at the second drive.
This solution does not appear to work:
If I copy the data file to the same folder where the Index.html file is and enter navigate to the URL httm://127.0.0.1:324324/Data_File.xlsx I get the file downloaded.
If I enter httm://127.0.0.1:324324/MyShortcut/Data_File.xlsx (where MyShortcut points to a folder in drive D) the attempt fails.
How can I achieve this?
The need to access files in the different drive is essential.
You need to configure your server to serve that folder under different location. The only reason you are able to see your app and access that folder is cause server is set up to serve it ATM, not because you are making the right calls from the front or cause the front is asking nicely.
Don't know what Windows server version you are using and IIS version that goes on it, or are you even using IIS (you most probably do) but depending on what you use you need to do something in a lines of this:
IIS7 config
What you probably wanna do is create virtual folder in IIS. Try looking into it, then if you fail ask a question with proper tags according where are you stuck.
I don't see how this is connected to front-end at all so front end tags wont get you far.
EDIT:
Oh, in that case get a second file server running for that folder? This should be the fastest way, use what you can from this list: list
I have a domain www.foo.com and wish to host a JAX-RS/Maven/Jersey web service there. Currently, I'm packaging the Java code into a .war file and deploying it on an Apache Tomcat 8.0 web server for testing on my local machine.
In /apache8/webapps/ROOT/index.html (localhost:8080/) I have script tags within which an XMLHttpRequest object makes a get request to localhost:8080/apiIndex/webapi/resource - which searches a resource folder in my web service directory that contains 150 or so images. The the full path names to those images are returned to my Js code, and that Js code attempts to create images out of them to be drawn to a canvas.
The problem is, I'm getting a network error saying that Js can't find/load the images.
How do I map an index.html file to my domain from within my web service directory, so that when I forward requests from my domain to port 8080 of my server I can access those images from code within my web service package? Is this the reason the Js code in the tomcat webapps folder can't load the images from my API's src/java/resources folder?
First of all: /apache8/webapps/index.html does not sound like something that's mapped to localhost:8080. I'd rather expect the / (root) webapplication to be deployed under /apache8/webapps/ROOT (and the index.html file within that folder).
I'm assuming that your web application with the images is deployed under /apache8/webapps/apiIndex. If that generates, as you say "the full path names" of your images, that can't be found: What are those full path names, and where do you expect them to be? Do you get 404 error codes or something else - like 500? Please post URLs and your expected places in the folder.
(this is posted as an answer instead of a comment because I hope that the initial description help you find the root of your problem yourself, while the second part is effectively asking for more information)
Edit: Following your comment: IMHO your webservice should rather return a http or https reference to an image, rather than a file reference. If anything else, you might need to prefix it with file:///home/... in order for the browser to consider getting it. However, if your browser shows a http document, it might not even cross that domain and embed local file resources for security reasons: Why would any webserver reference material on your local disk?
Have your images somewhere where you can reference them through http and the problem should be solved.
I'm testing some of the new JS filesystem abilities, i.e. creating an empty text file in the local filesystem. I'm running the HTML & JS files from a local path (file:///). For this purpose I launched Google Chrome with the --allow-file-access-from-files flag from the CLI. The filesystem request is PERSISTENT (and works).
I have read up on different posts about the filesystem, copied and modified some of the code in the tutorials; When I launch the HTML file, my custom success/ failure messages are outputted in the console;
This is the result:
Opened file system:/ // this is the root path of the JS Filesystem.
/wtf.txt // this is the name and path of the text file I created+ it's a success
However, when I look at my directory's (both system and application root), there's no .txt file with the name I assigned to it. How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)? What does it mean that the FileSystem is a 'sandbox'? That I cannot access the (virtual?) contents of it on my local drive, but only with JS? If this is the case, is there a way to prompt the user to save the file?
Thanks in advance for your answers
It seems you're expecting the File System API to work locally similar to an OS file system. The client doesn't work like that. In fact, and API is designed to be your interface, as a programmer, to the files and directories -- the client itself (e.g., Chrome, etc.) will handle the rest on the local level. The API is not designed by which you can create a file via the browser and easily access it via the operating system.
How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)?
Technically speaking, each client can store locally as it chooses. So while you can go to the local file system to look for the file, something is wrong with your approach if you're attempting to do so; the File System API is not meant for that. To your question, you can assume that if there's content the client's storage area (e.g., for Chrome it's something like "C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\File System\") then you can assume that the JavaScript wrote it. But again, it's not set up for user friendly browsing on the local system.
What does it mean that the FileSystem is a 'sandbox'?
Sandbox simply means an area created and set aside for a specific purpose, outside of which the client cannot see/access. See this from Mozilla: https://developer.mozilla.org/en-US/docs/WebGuide/API/File_System/Introduction#virtual
That I cannot access the (virtual?) contents of it on my local drive, but only with JS?
That is correct, and by design.
If this is the case, is there a way to prompt the user to save the file?
If I understand your question right, you're asking if there is a way to provide a specific file to the user and have it prompt them to save it locally. Well, of course if you provide a link to the file (or push it, a different discussion) then the client will prompt the user to save/store it if their platform allows them to do so. But you have no control over where they save it locally nor can you later get it it. If I've misunderstood your question, comment below and I'll follow up.
I'm trying to link to the directory above the web root, but it doesn't work in JavaScript. It doesn't matter how many ../ I use, it doesn't go more than twice, which is required to reach the web root. (Using PHP this works fine, though) I think it should be possible right? Could it be a permission problem? Thanks.
JavaScript is clientside -- it runs on the browser, not the server. A correctly set up server will not let clients access stuff outside the designated area, independent of whether it's from entering an URL into the addressbar, a link contained in an HTML page, or a URL created by JavaScript. It's all the same for the server anyway -- it's just an URL.
If you want to reach website root name, It's here:
var root = location.protocol + '//' + location.host;
//For a url, let say 'http://google.com/ig', it will return 'http://google.com'
But, Christian Stieber's answer is right If you want to reach any of server's file.
Javascript works on the client side. Client side doesn't know anything about the fylesystem of server so can't know or access anything there - client's root is domain name and adding one more '..' means trying to dive above domain name, not above one level in filesystem.
You can't link to a folder above the web root, because it simply doesn't exist.
You link to a web resource, not a physical folder. This resource usually corresponds to a file or folder stored physically on the server, but it doesn't have to. When it does correspond to a file or folder in the file system, it's only folders under the folder corresponding to the web root that is a part of the resources in that web. Anything above the folder is simply not part of the web. Eventhough it exists in the file system, it doesn't exist as a web resource.