So like imgur or youtube for example.
Both have the url blahblahblah.com/filename.(something) and you can see that particular file as it is located there.
Subdomain may be the incorrect name for something like that.
I want to create a website where users can create those extensions.
So users can create files on the server.
What would this be called.
I am just looking for keywords to google search.
It's usually referred to as a Content Delivery Network or CDN. There are many examples of third party CDN's, such as Akamai or Cachefly. Huge corporations like Google have the resources to create their own and still get the same efficiency advantage.
The advantage to using a CDN is that the web servers are optimized for delivery of static content such as images, CSS, JavaScript, or downloadable content. They take advantage of robust caching schemes to avoid files being downloaded by a browser on each visit. Some third party solutions, especially Akamai, also have the added advantage of having servers within one hop of almost everyone on the planet.
A YouTube example looks like this...
http://s.ytimg.com/yts/img/feed/promo-home-icon-vflGvCgAU.png
More about Content Delivery Networks.
Subdomains look like this subdomain.example.com. Anything after the domain name is called URI (Uniform Resource Identifier). ei, example.com/news/headline or example.com?news=headline
Related
I'm new to coding, quite obviously. I created a web design using HTML in Adobe brackets. How do I create my own website from here? Like getting a domain or host. Not sure if those are even the right words to use
Welcome to the wonderful world of web development! Congrats on making your first HTML site.
I am not sure how much you know about the topic, so I will try to explain the basics of getting a site "online".
Websites essentially allow you to access other people's HTML documents in a file directory. You have probably noticed some URLs in the form "www.example.com/file.html". This means that to get your site online, you will need a computer to "host" your HTML files from. Since you probably don't want to leave your computer on 24/7, you will need to use a web hosting service. There are loads of web hosting companies that offer similar services, but they all have the same goal essentially - providing the means for people to remotely access your files. My hosting service of choice is Digital Ocean because they offer a decent price on a small web server. Through your web server (which is essentially a computer running Linux in a warehouse somewhere), you can install web server software (like Apache) which will allow you place your html files into a special directory which will can be accessed from a web browser (something like /var/www/html). Once your files are uploaded to your server, you can access your website through your server's IP address (some esoteric number in the form of http://xxx.xxx.xxx.xxx).
Of course, you don't access websites through an IP address (at least most humans don't). This is where a "domain name" comes in. The web provides a nifty feature (DNS) which allows you to map a domain name to an IP address. So you can go to your favorite domain purchasing website (something like GoDaddy, which you have probably heard of) and purchase an open domain name of choice. Once you purchase the domain (something like DragonFire09.com), you can map this domain name to your web server's IP address.
These are the two main steps to getting a site online! I hope this provides some insight. Note that getting a website online costs money because you need to pay for a hosting service and a domain, however its a great experience because along the way you will get your hands dirty with Linux and other parts of the web stack.
Of course, you can always create files locally and test them through your own web browser free of charge.
Good luck!
At my company we are redesiging our e-commerce website. HTML and CSS is re-written from the ground up to make the website responsive / mobile friendly.
Since it concerns one of our biggest websites which is responsible for generating of over 80% of our revenue it is very important that nothing goes "wrong".
Our application is running on a LAMP stack.
What are the best practices for testing a major redesign?
Some issues i am thinking of:
When a/b testing a whole design (if possible) i guess you definitaly
dont want Google to come by and index youre new design (since its
still in test phase). How to handle this?
Should you redirect a percentage of the users to a new url (or
perhaps subdomain)? Or is it better to serve the new content from the
existing indexed urls based on session?
How to compare statistics from a Google Analytics point of view?
How to hint Google about a new design? Should i e.g.
create a new UA code?
Solution might be to set a cookie only for customers who enter the website via the homepage. Doing so, you're excluding adwords traffic and returning visitors, who might be expecting an other webdesign, serve them the original website and leave their experience untouched.
Start the test with home traffic only, set cookie and redirect a percentage to a subdomain. Measure conversion rate by a dimension in Google analytics, within same analytics account. Set a 'disallow subdomain' in your robots.txt to exclude the subdomain from crawling by SE's.
Marc, You’re mixing a few different concerns here:
Instrumentation. If you changes can be expressed via HTML/CSS/JavaScript only, i.e. optimizational in nature, you may be able to instrument using tols like VWO or Optimizely. If there are server side changes too, then a tool like Sitespect (any server stack) or Variant (Java only) might be in order. The advantange of using a commecial product is that they provide a number of important features out of the box, e.g. collecting experiment data, experience stability (returning user sees the same experience), etc. You may be able to instrument on your own, but unless you’re looking at a handful of pages, that typically is hard, particularly if you want to do it outside of the app, via the DevOps mechanisms.
SEO. If you get your instrumentation right, this shouldn’t be an issue. Public URIs should not differ for the control and variant of the same resource.
Traffic routing. Another reason to consider a commercial tool. They factor that out of your app and let you set percentages. Some tools, like Variant, will allow you to write custom targeters, e.g. “value” users always see control.
I am learning the html course from the available tutorials on the internet. And with that knowledge I have developed some html files and I believe there is more to go. These files consist of our old school friends and their present condition and what they're doing. I have created a bunch of html files. Like I have created a website for now named as www.mypage.com
Arjun
So in the href I'm just giving the path but those files are in my desktop pc itself. How do I put them on internet and share with my friends who are living somewhere out of this town. I want to reunite all of my school friends using these files. But where do I upload them and make it like a webiste to my friends? Is there any free way to do that? Or any possible way to reach it.
And I'm saying sorry if the question is not for the tag I mentioned. Please let me know and I remove the tag. I don't know what is the link to wikiposts to share my views. If you know then let me see the link. Thank you.
Find a web hosting service (Google knows lots)
Sign up
Follow their instructions
Arjun
And use relative uris
I use http://webhosting.uk.com ... for about £32 a year you get asp.net hosting and access to sql server.
then you simply ftp up to your website something like this (using windows explorer) ....
ftp://mysite.com <-- not a real link
... that would then open up the remote server as if it was a local folder so you could drag and drop your files straight over.
there's an online chat link on the top right of the homepage, the support staff will walk you through getting setup.
don't forget though ... the cost of the domain name that's the bit that turns your server ip address in to stuff like google.co.uk ... I highly recommend them.
I shall just expand on Quentin's answer, because it is clear that you are new.
What you need is a web hosting service. This is a service which hosts your html pages, meaning stores them in their own computers, and also displays them to the world as webpages. Web hosting services are usually paid, but there are some excellent free services if your content is not too big. A simple and free service that I would recommend is Google Sites. You could also try Google App Engine, where you have more freedom and control over your content, but for the same reason it is a little more advanced. But since you are learning html, I believe it is a wise idea to learn more about these services and related concepts.
When you upload your files, the html links need to be changed. They can no longer point to files in your hard drive. When you upload these files, there will be a directory structure in it. All you need to do is place hyperlinks with relative addresses.
And about what your website will be called, www.whatever.com, that is quite another business. For that, you need to register your own domain name, for which you must pay. If you don't want to, then your website will be labelled something under the hosting service domain name. This forum is not adequate to go into a more elaborate explanation of all this, but I think I have mentioned all the key terms, so do some research!
I've got a few HTML pages with the requisite images, css and other bits and pieces, all static content no CGI required. I currently host it on an Amazon EC2 image that I need to have up and running for a different application. Ideally I'd like to move the hosting of the static content off the EC2 image so that it's independent of any single EC2 instance. I'd like to host it on one of the free or at least pay as you go cloud options.
The options I've come across are:
Windows Azure, in this case I haven't been able to get .html pages working and even if it is possible would it mean I'd have to update the whole Windows Azure app everytime I needed to update an image? Or is there an easy way static web content could be served up from Azure blobs?
Amazon's S3, I think I'd have to put fully qualified URL's into each HTML page for each image, css etc. file but that wouldn't be too bad. This seems like a reasonable option.
Google's App Engine, only spent 10 minutes looking at it but it seems like it would work as well.
Wordpress, I could just incorporate the HTML into a wordpress blog site but I find the themes a little bit too restrictive, pages can only be so wide etc.
Is there an easier way?
Update:
After some further investigation the two best ways I found are the S3 approach as described by Sug and Windows Azure Blob storage (rather than a Windows Azure service).
The difference between S3 and Azure Blobs is how the CNAME can be managed:
For S3 you'll end up with a CNAME like mybucket.mydomain.com
For Azure you'll end up with a CNAME like *.mydomain.com where * represents whatever you like. To access blobs the path is then *.mydomain.com/container/.
So S3 dictates the CNAME host but gives full flexibility on the resource path. Azure gives full flexibility on the CNAME host but dictates the first part of the resource path.
For serving only static files, using services like AppEngine or Azure will be over kill.
The simplest solution will be to use AWS S3:
1) No coding required
2) Pricing
3) You can easily map a bucket to your own domain or subdomain.
4) Free client tools to manage your buckets as it was dead simple filesystem.
I personally use S3Fox but there are many others (BucketExplorer is another example)
“S3 dictates the CNAME host”
Amazon has a CDN service called CloudFront, that uses an S3 bucket for storage. You only pay for S3 data transfer (I think).
Your bucket contents are copied to Amazon’s CDN, meaning superfast access from around the world. However, because it’s a CDN, files are automatically cached for a long time (so there’s a delay when re-naming or deleting files).
Just using an S3 bucket, and setting up another domain to point to the bucket via a CNAME, might be the best idea.
For simple sites like this, I've had good experiences with Nearly Free Speech.Net.
GitHub.com pages. You just need to know Git basics, check out the gh-pages branch, and put the static content there. It will be available at http://your-name.github.io/your-project/
For example, this is my project's file.
We have several images and PDF documents that are available via our website. These images and documents are stored in source control and are copied content on deployment. We are considering creating a separate image server to put our stock images and PDF docs on - thus significantly decreasing the bulk of our deployment package.
Does anyone have experience with this approach?
I am wondering about any "gotchas" - like XSS issues and/or browser issues delivering content from the alternate sub-domain?
Pro:
Many browsers will only allocate two sockets to downloading assets from a single host. So if index.html is downloaded from www.domain.com and it references 6 image files, 3 javascript files, and 3 CSS files (all on www.domain.com), the browser will download them 2 at a time, with the other blocking until a socket is free.
If you pull the 6 image files off onto a separate host, say images.domain.com, you get an extra two sockets dedicated to download your images. This parallelizes the asset download process so, in theory, your page could render twice as fast.
Con:
If you're using SSL, you would need to either get an additional single-host SSL certificate for images.domain.com or a wildcard SSL certificate for *.domain.com (matches any subdomain). Failure to do so will generate a warning in the browser saying the page contains mixed secure and insecure content.
You will also, with a different domain, not send the cookies data with every request. This can increase performance.
Another thing not yet mentioned is that you can use different web servers to serve different sorts of content. For example, your static content could be served via lighttpd or nginx while still serving your dynamic content off Apache.
Pros:
-load balancing
-isolating a different functionality
Cons:
-more work (when you create a page on the main site you would have to maintain the resources on the separate server)
Things like XSS is a problem of code not sanitizing input (or output for that matter). The only issue that could arise is if you have sub-domain specific cookies that are used for authentication.. but that's really a trivial fix.
If you're serving HTTPS and you serve an image from an HTTP domain then you'll get browser security alert warnings pop up when you use it.
So if you do HTTPS, you'll need to buy HTTPS for your image domain awell if you don't want to annoy the hell out of your users :)
There are other ways around this, but it's not particularly in the scope of this answer - it was just a warning!