I just read a little tutorial on SSI and managed to show what I wantedbut I'd like to use an http path to point at this file so I can use it with sites in differente servers. How can I do it?
The path of the file I want to show is "http://chusmix.com/menubar/bar.html"
Thanks!
If you really want to, you can write up a CGI script that simply calls wget or curl, on the desired url and include it via a virtual include call.
<!--#include virtual="/cgi-bin/url_getter.cgi?url=YOUR_URL" -->
That's the safest bet. If you want to do something a little less secure, you can do it via a direct call to wget or curl via an exec include call.
<!--#exec cmd="wget YOUR_URL" -->
Most hosting providers disable the exec call by default because it really isn't a good idea to use it. Don't use it, use a virtual call instead.
But to be honest, just including external pages like that is pretty unsafe, unless you happen to also control the page on the other server. Don't forget that the other page could contain javascript and hence do undesirable things to visitors of your page, who implicitly trust you, but maybe not the external source.
You cannot reference a URL with the #include SSI directive in either IIS or Apache.
The only way to "include" remote content is to use Javascript (possibly with Ajax) or a server-side HTTP request.
Related
is it possible, or how could I make it so, I can include my topbar file into my page, I'd prefer it not to be with php since I am not hooked up with localhost yet.
Thanks for all help in advance!
HTML5 now allows you to include html files like you can already include a css file via an import. However, this would only be helpful for during your development stages and not for the final production version since the feature currently is only available in Chrome and will take time for the other browsers to adopt: http://www.html5rocks.com/en/tutorials/webcomponents/imports/
If you don't want to use PHP nor any other server-side scripting language,
you can use either <iframe> or <frameset> tags, which are deprecated, or perform an AJAX request using Javascript that embeds your HTML page dynamically. Second approach will work only if the page you're trying to attach is located within the same domain due to XSS protection in modern browsers.
It's more of a server thing, so to speak, so you would have to rely on the server more for this. Because, you cannot simply do this using static script, like HTML. There's no "built-in function" that can do this, it's not HTML's thing.
I mean, server will offer you more than one option, for example:
You can:
Use SSI (Server-side Includes) if server supports it.
Use PHP or ASP includes.
Otherwise, you can use AJAX for this, won't cost you as much as the above options.
If you mean "header" by saying "topbar", I think it's not a good idea to use iframes.
Files which are truly HTML parsed files can not include another file to my knowledge.
If you web server will parse php you could simply change the extension of the the main file to .php and include() the topbar file:
mv index.html index.php
index.php:
include_once("topbar.html");
Use <!--#include file="footer_text.html" -->
inside html page.
Plz, check below url for details.
https://www.lifewire.com/include-html-file-in-another-3469529
I am loading content from another page and depending on the content of page, changing content of my page and this is giving me cross site scripting issues.
When i use iframe, since the content is from other domain, content of iframe becomes inaccessible.
When i use ajax and try to inject the content as plain html code, XmlHttpRequest object throws permission denied exception due to cross site scripting.
When i use JSONP, such as getJSON in JQuery, it only supports GET protocol and it is not adequate for further processing.
I wonder what other options i can try. Heard that DOJO, GWT,Adobe Air do some XSS, but dont know which one is the best.
Thanks,
Ebe.
Without JSON-P, your only option is to run a proxy script on your own server that fetches the content from the external site and pipes it back to the browser.
The browser fetches the content from the script on your server, hence no cross-domain issues, but the script on your server dynamically fetches it from the external site.
There's an example of such a script in PHP here: http://www.daniweb.com/code/snippet494.html (NB. I haven't personally used it).
If you have control over both domains, take a look at EasyXDM. It's a library which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.
To add to what RichieHindle says, there are some good script (Python+Cron) that you can plonk on your server and it will check for changes to a POST/GET location and cache the changes on your server.
Either set your triggers low (once every 10 mins/ 1 per day) or you might get blacklisted from the target.
This way, a local cache won't incur the HTTP overhead on every AJAX call from the client.
I am a total noob on this issue, and I wonder if I have to do that where I put the code :
In the virtual host / apache conf file ?
In a httaccess file ?
Redirect all URLs to a single entry point and parse it with a scripting language ?
What are the pro and cons ?
I'd tend to go with the .htaccess because it's easier to maintain as part of a project's files, doesn't require kicking the web server to take effect, and will typically be faster than scripting-level rewrites.
This depends on what exactly you want to do.
Rewriting rules should go in the configuration relating to the directory/site root which is typically your vhost configuration or htaccess (depending on setup).
Doing this through a script only makes sense if your redirect is based on extra information such as matching a 404 to a database of recently moved pages or a 404-URI to a search of some kind.
OK, so I put some summary of what I read on SO about it :
URL rewriting for redirection :
Better to put that in the Apache configuration. using .htaccess is the most flexible way but your Apache conf must allow it, if not, set the rewriting in the Vhost file.
URL rewriting for ressource management :
When it's about managing not found contents, access right or getting clean URL for accessing dynamic contents, you need to set the rewriting in the script file of your app since it's where you have access to the API to handle this kind of things.
So both of the ways are complementary, and you will usually use both at the same time.
.htaccess file in the directory should best place if you dont have any speed optimization concerns. And its also the way to go if your site is hosted on shared webhotel or your web application can create the htaccess files by itself.
Personally i prefer to have every configuration option in the virtualhost config file but thats good only if you have the root access.
It depends if you also need to do outbound URL-rewriting (the modification of links in the actual HTML pages themselves,) in which case, a tool like MOD_REWRITE will not do the trick for you, and you will need to use an "internal" or "native server-side" tool, in the case of Java, you would use something like PrettyFaces, or Rewrite.
These tools can also do the same type of inbound rewriting (like sending redirects to new pages, or forwarding to a new internal resource so that users do not know they are seeing an address/URL change.
My general rule of thumb, however, is that if the URL-rewrite rules need to be available when the application is running, you should use something like MOD_REWRITE, but if the rules only apply to that application itself, then they belong inside the application and you should use a native tool.
When I look at Amazon.com and I see their URL for pages, it does not have .htm, .html or .php at the end of the URL.
It is like:
http://www.amazon.com/books-used-books-textbooks/b/ref=topnav_storetab_b?ie=UTF8&node=283155
Why and how? What kind of extension is that?
Your browser doesn't care about the extension of the file, only the content type that the server reports. (Well, unless you use IE because at Microsoft they think they know more about what you're serving up than you do). If your server reports that the content being served up is Content-Type: text/html, then your browser is supposed to treat it like it's HTML no matter what the file name is.
Typically, it's implemented using a URL rewriting scheme of some description. The basic notion is that the web should be moving to addressing resources with proper URIs, not classic old URLs which leak implementation detail, and which are vulnerable to future changes as a result.
A thorough discussion of the topic can be found in Tim Berners-Lee's article Cool URIs Don't Change, which argues in favour of reducing the irrelevant cruft in URIs as a means of helping to avoid the problems that occur when implementations do change, and when resources do move to a different URL. The article itself contains good general advice on planning out a URI scheme, and is well worth a read.
More specifically than most of these answers:
Web content doesn't use the file extension to determine what kind of file is being served (unless you're Internet Explorer). Instead, they use the Content-type HTTP header, which is sent down the wire before the content of the image, HTML page, download, or whatever. For example:
Content-type: text/html
denotes that the page you are viewing should be interpreted as HTML, and
Content-type: image/png
denotes that the page is a PNG image.
Web servers often use the file extension if the file is served directly from disk to determine what Content-type to assign, but web applications can also generate pages with any Content-type they like in response to a request. No matter the filename's structure or extension, so long as the actual content of the page matches with the declared Content-type, the data renders as intended.
For websites that use Apache, they are probably using mod_rewrite that enables them to rewrite URLS (and make them more user and SEO friendly)
You can read more here http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
and here http://www.sitepoint.com/article/apache-mod_rewrite-examples/
EDIT: There are rewriting modules for IIS as well.
Traditionally the file extension represents the file that is being served.
For example
http://someserver/somepath/image.jpg
Later that same approach was used to allow a script process the parameter
http://somerverser/somepath/script.php?param=1234&other=7890
In this case the file was a php script that process the "request" and presented a dinamically created file.
Nowadays, the applications are much more complex than that ( namely amazon that you metioned )
Then there is no a single script that handles the request ( but a much more complex app wit several files/methods/functions/object etc ) , and the url is more like the entry point for a web application ( it may have an script behind but that another thing ) so now web apps like amazon, and yes stackoverflow don't show an file in the URL but anything comming is processed by the app in the server side.
websites urls without file extension?
Here I questions represents the webapp and 322747 the parameter
I hope this little explanation helps you to understand better all the other answers.
Well how about a having an index.html file in the directory and then you type the path into the browser? I see that my Firefox and IE7 both put the trailing slash in automatically, I don't have to type it. This is more suited to people like me that do not think every single url on earth should invoke php, perl, cgi and 10,000 other applications just in order to sent a few kilobytes of data.
A lot of people are using an more "RESTful" type architecture... or at least, REST-looking URLs.
This site (StackOverflow) dosn't show a file extension... it's using ASP.NET MVC.
Depending on the settings of your server you can use (or not) any extension you want. You could even set extensions to be ".JamesRocks" but it won't be very helpful :)
Anyways just in case you're new to web programming all that gibberish on the end there are arguments to a GET operation, and not the page's extension.
A number of posts have mentioned this, and I'll weigh in. It absolutely is a URL rewriting system, and a number of platforms have ways to implement this.
I've worked for a few larger ecommerce sites, and it is now a very important part of the web presence, and offers a number of advantages.
I would recommend taking the technology you want to work with, and researching samples of the URL rewriting mechanism for that platform. For .NET, for example, there google 'asp.net url rewriting' or use an add-on framework like MVC, which does this functionality out of the box.
In Django (a web application framework for python), you design the URLs yourself, independent of any file name, or even any path on the server for that matter.
You just say something like "I want /news/<number>/ urls to be handled by this function"
i have two servers a main site and a static server.
i want to get a file's content from ajax in runtime, which is stored in static server.
obviously cross domain problem will occur.
so what i am trying to do is storing that ajax .js in the static server, so that calling the local file wont be a problem.
but after i include that js file from static, still that problem remains...
Any solutions?!
n't use X domain Ajax Requests. Create a "proxy" on your own server (domain) then forward the call to the other domain, cache it, check for security issues and send it back to client again...
Depending on the information you want your ajax request to recieve you could always use something like jsonp which could have the cross-site call.
try looking here for some examples:
http://remysharp.com/2007/10/08/what-is-jsonp/
Take a look at EasyXDM. It's a library which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.