For my mobile application I want to use pushState and AppCache, but this seems to be tricky.
To make pushState work, my web server redirects every url (except assets like the manifest file itself, images, css- and js files) to /index.html internally.
E.g. a request to /articles/123 will redirect to / respectively /index.html (so the originally requested URL is still visible in the browser).
This causes the request to the manifest.appcache to a wrong path, like /articles/123/manifest.appcache instead of /manifest.appcache, which leads us to the problem that the browser creates a new cache group for every directly accessed URL (e.g. by a Google search)
I redirect (.*)/manifest\\.appcache to /manifest.appcache and it is interpreted, so that should work as expected. I think the main issue is that the browser treats the manifest.appcache file on URL level instead of domain level.
So this leads me to the following questions:
Is this a practicable approach?
If yes, can I tell the browser to use the AppCache on domain level and how?
If no, what am I not thinking through?
When you put the manifest attribute on the <HTML> element just set the path properly to point to the root directory:
<html manifest="/appcache.manifest">
Related
What I'm trying to do is have a single dynamic file that takes a parameter to affect content (/view.html?k=about) but uses history.pushState to change the URL to something more user-friendly (ki/about). In addition, anytime an AJAX call is made on content.html to load new content, it updates the URL according, (e.g. if products are loaded via AJAX, change URL to keywords/products).
My current solution is any path requested from ki is redirected via .htaccess to the view.html page. view.html then uses history.pushState to change the URL. As links are clicked, the URL updates. The problem with this, however, is it causes a infinite loop.
Here is my .htaccess file, residing in the /ki/ folder.
RewriteEngine on
RewriteRule ^(.*)$ /concept/view.html?k=$1 [R=permanent,L]
What can I do to get my desired result? If there's a way to achieve the same thing without the .htaccess file then that's acceptable too.
You are going to want to rewrite any url that goes in the form of ki/about to the /view.html?k=about behind the scenes.
history.pushState is only really meant to be used for web applictions like Spotify that don't reload the page but would still make sense to have the back button have some functionality.
That way, urls can be shared without giving 404 pages.
I have not tested this but I am sure you want something like this
RewriteRule ^ki/([A-Za-z]+)/$ /view.html?ki=$1
If the user types in the ugly url, they will still get to the same page no problem. But the pretty urls will direct users to the right webpage.
For more info you can go here.
http://www.yourhtmlsource.com/sitemanagement/urlrewriting.html
Suppose I had a URL in my browser location bar that read:
http://www.example.com/us/books
... how do I code the url in the page so that it'll add to the address in the location bar?
Example
Url in location bar: http://www.example.com/us/books
Url on page: Read more
Desired
http://www.example.com/us/books/this-title
No matter what I do, It wont appear after the entire URL. The URL isn't fixed.
This approach of using a relative path inside a reference does work. But you have to figure out some details which depend on your local situation.
In your case most likely the target url called is http://www.example.com/us/this-title (you did not tell us...). This is due to the fact how the browser (not the server!) interprets its current position inside the document hierarchy on the server.
If your base url reads http://www.example.com/us/books/ (note the trailing "/") then things would work as expected by you! You could even note the relative path as Read more. This works because the browser recognizes the current position as a folder and assumes the relative path to be located inside. This works for example when the html page holding that reference is delivered by an index document (index.html, index.php or similar) on the server. This is when the trailing slash makes sense, since it denotes that the current url retrieved the content of a folder, not a directoy.
Of course this is only what is happening on the client side. It might be that the server decides to rewrite the url and redirect the browser again. For example by using rewrite rules inside the http server. This is typically done to handle requests to non existing documents.
I am a beginner with node.js and am using express with the ejs layout, and I want to know how to get rid of the .html extension when putting up a page. For example if I go to my localhost:3000/about.html - that works but I want it to show up as just /about. Also, having trouble figuring out how to change the favicon if anyone knows how to quickly change that from the express default.
Any help would be great thanks.
(I realise this question is old, but it appears high in Google search results, and the accepted answer isn't the best solution.)
The best solution for serving up static content in express.js is express.static. To avoid having to specify file extensions in URLs you can configure it with a list of default file extensions that it will use when searching for static files:
app.use(express.static(pathToBaseFolderOfStaticContent, {
extensions: ['html', 'htm'],
... // Other options here
}));
This will serve up pathToBaseFolderOfStaticContent/somePage.html or pathToBaseFolderOfStaticContent/somePage.htm in response to a GET request to http://www.example.com/somePage, which is what you want. For example, if you visit https://arcade.ly/star-castle, the file it serves up is just a static file called star-castle.html. I haven't had to add any special routing for this, or any other static file - it's all just handled by express.static.
I only need to add specific routes for content that requires active work on the server to return. A big advantage here is that I can use a CDN to cache more of my content (or nginx if I were running an internal line of business app), thus reducing load on my server.
You can obviously configure as many default file extensions as you like, although I'd tend to keep the list short. I only use it for resources where the URL is likely to appear in the address bar, which generally means HTML files, although not always.
Have a look at the following documentation on serving static content with express.js:
http://expressjs.com/en/starter/static-files.html
http://expressjs.com/en/4x/api.html (the express.static documentation is at the top)
This is also answered at In express what is the common way to associate a default file extension with static content requests?.
The favicon.ico issue can be solved by dropping your favicon into the root folder from which you serve static content, as well as implementing +Costa's solution where you reference it using a <link> in the <head> of your documents.
In theory you shouldn't need to do put the favicon in the root folder but, in practice, some browsers will still ask for it from the site root even though it's referenced in the <head> of your document. This leads to a spurious 404 error that you'll be able to see in client side debugging tools (e.g., Chrome dev tools).
The Favicon issue is usually a caching problem. As long as you have this code in your base html layout:
<link rel="shortcut icon" type="image/x-icon" href="/images/favicon.ico">
Then just navigate to wherever that image is with your browser, and that should force your cache to update.
I figured it out. I looked at this post Render basic HTML view? which solved the problem I was having.
app.engine('html', require('ejs').renderFile);
app.get('/', function(req, res){
res.render("index.html");
});
And this all goes in the app.js or whatever file you are running.
Still working on my personal web server, I was trying to use the html5 audio and video tags within Nitrogen.
As there is no #audio nor #video records, I decided to insert html text directly in the page generated by nitrogen, the result looks like this:
<audio controls preload="metadata"><source src="../../My Music/subdir/song.ogg" type="audio/ogg" /source>audio tags not supported</audio>
In my understanding this should work because the audio tag is supposed to be interpreted directly by the client browser, and there is not any nitrogen id or event observer in the code.
But when I browse this code from Firefox, I briefly see the control opening, and then the audio element simply disappears.
If I copy paste the whole code generated by nitrogen (display html source page, copy and paste in a file located at the origin of the nitrogen project) and open it with the browser, it works fine. The relative path is correct, assuming that the search stats in nitrogen project. I have tried absolute path also, without success.
I don't know
if it builds a file name of the form ".._.._My music_subdir_song.ogg" like nitrogen does for url analysis,
or if it uses another directory to start the path,
or if it simply doesn't work the way I am thinking.
...
Edit: some complementary information:
I have done the following changes:
create one directory including some ogg files in the site/static directory + move a static test.html file in the site/static. If I open directly test.html -> ok. if I redirect from my web site -> Not ok.
same test with a copy of the directory at the Nitrogen application root and access from my web site -> not ok
As the information on the web page is ambiguous, I modified test.html to access to a file that does not exist on my PC -> same behavior.
I think I'll use the debugger to understand how the request is managed, to be continued...
Edit 2:
using the debugger I can verify that the wf_core:run_catched() is called several times. The fist call is when it process the event in my page that redirect to the static file.
The second time to process the static html file itself.
A third time to process finish_static_request() with a Path equal to my_music/song.ogg, and then I get lost in the processing of the answer. Another wf_core:run_catched() was called in parallel, but I didn't follow it...
I have been able to verify that the file can be accessed: I have added several audio tag in the html files, and I was able to "download" the existing files using the DownloadHelper Firefox plugin.
My understanding now is that the path is correct (at least when I place the files in a subdirectory of site/static), the server is able to retrieve the files and send them, the browser recognize the audio and video tags, but the link between the embedded audio/video reader and the files is lost, although I have added a type definition inside the audio tag.
Any idea to continue?
Edit 3:
Finally I got it. As Chops suggest it I had to go in the inets server configuration, not to define the path, but to define the type association. I have added the following definitions in etc/inets_httpd.erlenv, and it works.
{mime_types, [
{"css", "text/css"},
...
{"ogg","audio/ogg"},
{"webm","video/webm"}
]}
:o)
Based on the contents of the url attribute ("../../My Music/subdir/song.ogg"), the problem, when it's served from Nitrogen is that the request (Assuming you're using the default 127.0.0.1:8000) for the audio will be to the url "http://127.0.0.1:8000/My Music/subdir/song.ogg"
What you want to to do, if you're using the standard Nitrogen installation, is to put the song files you want into the site/static directory, perhaps in "songs" subdirectory.
Then change the url attribute to be "/songs/mysong.ogg" (or whatever path within site/static you used).
Note: Dependinding on your server choice (Webmachine, for example), you may need to tinker with the server's specific config file to tell it to handle the new directory for static paths, for help, check the configuration docs on the Nitrogen site.
Beyond that, there's nothing special about outputting raw HTML in Nitrogen. It is my understanding that the problem here is really just related to the paths of the requests being sent to the server.
from Dive into HTML5: Cache Manifest: Fallback section
CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
i dont understand from the URL given what this block of code exactly does. does the fallback section mean when anything is not found, show the offline.html page
then network: * all resources will be cached? it says also
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
this seems to conflict to network: * where it seems to say cache everything?
There are three types of headings in a cache manifest, CACHE, NETWORK and FALLBACK. Anything that is not under a heading is implicitly set under CACHE. An explanation of each section:
CACHE: Files under this heading will be cached.
NETWORK: Files under this heading require an internet connection and so will be NOT be cached.
FALLBACK: Files matched by patterns under this heading (Such as the pattern "/", which matches all files) and have not been cached, will have a fallback file shown instead.
With regards to the block of code from Dive into HTML 5, there is an explanation of the "NETWORK: *" part just under it:
It means that, while you’re browsing
this hypothetical offline-enabled
Wikipedia online, your browser will
fetch images and videos and other
embedded resources normally, even if
they are on a different domain. (This
is common in large websites, even if
they aren’t part of an offline web
application. HTML pages are generated
and served locally, while images and
videos are served from a CDN on
another domain.) Without this wildcard
flag, our hypothetical offline-enabled
Wikipedia would behave strangely when
you were online — specifically, it
wouldn’t load any externally-hosted
images or videos!
The following quote:
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
means that you must include all necessary CSS, Javascript and image files in the manifest under the CACHE heading. It does not conflict with 'NETWORK: *' because the NETWORK heading does NOT mean 'cache everything'. It actually means the opposite: that everything under the NETWORK heading requires an internet connection and should not be cached.
I have found out more useful stuff about FALLBACK:
After a bit of experimenting, I tried various things including whether files in FALLBACK: should appear in the CACHE or NETWORK sections at all. The answer seems to be no.
As an example...
FALLBACK:
sign-up-portrait.png offline-portrait-1.png
sign-up-landscape.png offline-landscape-1.png
I specified this in one of my micro sites recently. The intention is to show the sign-up- png files when online and the offline- png files when offline. This works well. In particular the files on the left side of each line are implicitly as if they were in the NETWORK section, the site will always try to get them online. They must not be added to the NETWORK section as well, otherwise it seems to override what's in FALLBACK.
Plus, happily, the files on the right are implicitly as if added in the CACHE: section so even if they are not used at first, they are cached on first load without having to explicitly add them to CACHE: although you can add them there too if you want. It makes no difference.
For this configuration, looking at the webserver logs, I see that each time the page is refreshed, apache logs a 304 against the manifest file and against the sign-up- png file that's required for that version of the page (there's a CSS media selector determining which, based on page size). So it's correctly always checking for the sign-up- png files as well as the usual manifest checking, which is exactly what I want.
For the sake of being thorough, I tried to see if the root file needs to be in the CACHE: section too. It turns out it doesn't! If your top level file is index.html and it has the manifest file specified in its html tag then the manifest file need not contain index.html anywhere, it's implicitly cached.
I am curious how far the app cache can extend. Can you include other html files that are linked to or in iframes? Or do those all need to have their own manifest files that are separate? Anyone care to comment?
A side comment about format, don't make the mistake I did, which is to put in...
NETWORK
file1.js
Missing the colon causes it to totally break, thinking that NETWORK is a resource in its own right.
It must be...
NETWORK:
file1.js