I've created a subdomain to host all my images (e.g. http://images.domain.com, which points to my public_html/images/ folder). When I try to access a particular image via the browser, I am getting redirected. For example, I go to http://images.domain.com/foobar.jpg, I am redirected to http://www.domain.com/images/foobar.jpg.
Why would I get redirected? This is causing YSlow to lower my overall grade. Thanks.
Most likely is the web server that's serving the images domain (probably the only web server you have). Without info on the server you're using, it's impossible to tell you how to fix it, but it's definitely a configuration option in the server.
Related
I'm building a website, however the URL for the website is likely to change.
How can I load resources in the front end if the domain and installation directory is likely to change?
Now that I'm starting to get deep into building the backend I have some issues.
The url is about to change, what do I do now?
I can use PHP to get the current domain and have a preset installation directory. Then load it from a variable every time I need to load a resource.
Is there any other solutions, what would you recommend?
I'm talking about resources loaded through the browser, not ones loaded through php.
If the resources are housed under the same domain as your php app, you can simply remove the protocol and hostname from those links and let the browser figure it out.
If the resources are hosted on a different hostname (or via a different protocol - http vs. https for example) then your solution of using a variable is probably the best course.
This question already has an answer here:
Closed 12 years ago.
Possible Duplicate:
What’s the point in having “www” in a URL?
Hello, I have little to no experience owning a website but I am willing to learn all that there is to this process. However I am frustrated because I am constantly blocked by simple problems.
I just uploaded my first index.html page which is basically a background color and a title image. I put my favicon in the public_html directory right next to index.html. I immediately notice that it does not work. I also notice that I have typed http://website.com in the URL bar. I type "www" before "website" and the favicon shows up. I hit back and the favicon is blank again. What is the difference between the non-www version of the site and the www version of the site? Why does the favicon not show up? What other differences are there? Should I disable the non-www site like many professional sites seem to do? How do I do this? What are the advantages and disadvantages, if any?
Thank you.
The www-subdomain is just a convention amongst websites to indicate this address points to a World Wide Web server.
For example,
google.com is the top domainname of
the Google company.
www.google.com indicates this is the
domain name for the World Wide Web,
ftp.google.com indicates this is
probably an ftp-server.
But as it is just a convention, and the average user uses the internet mainly for www, most servers configure their http://domain.com to be aliases to http://www.domain.com.
Why the favicon on your site only shows up for the www-version and not for the topdomain, depends on your html and your server configuration. Can you post some code or link to your site?
The fully qualified domain names are different. So they are different websites.
Usually the two hostnames will point at the same IP address, and the server will be confiured to either serve up the same content for both or redirect from one to the other.
Redirecting from on to the other (and which way round you do it doesn't really matter) is generally considered good practice as it lets you be consistent (and saves you from issues such as XHR requests to a specific hostname breaking when used on the alternative).
The favicon not working is likely caused by your browser having cached that http://www.example.com/favicon.ico didn't exist and it not having yet checked again. http://example.com/favicon.ico, OTOH, is a different URI so it would have checked it the first time you went there (which was after you created the icon file).
Typically most of the server domain manager software like Cpanel and Plex are configured to serve same site for both domains. Cpanel do have a public_html and www separately, but same content.
I have an ASP.NET web site technology that I use for scores of clients. Each client gets their own web site (a copy of the core site that can then be customized). The web site includes a fair amount of content - articles on health and wellness - that is loaded from a central content server. I can load the html for these articles from a central content server by copying from the content server and then inserting the text into the page as it is produced.
Easy so far.
However, these articles have image references that point back to the central server. The problem that I have is due to the fact that these sites are always accessed (every page) via an SSL link. When a page with an external image reference is loaded, the visitor receives a message that the page "contains both secure and insecure elements" (or something similar) because the images come from the (unsecured) server. There is really no way around this.
So, in your judgment, is it better to:
A) just put a cert on the content server so I can get the images over SSL? Are there problems there due to the page content having two certs? Any other thoughts?
B) change the links to the article presentation page so they don't use SSL? They don't need SSL but the left side of the page contains lots of links to pages that do need - all of which are now relative links. Making them all absolute links is grody because each client's site has its own URL so all links would need to be generated in code (blech).
C) Something else that I haven't thought of? This is where I am hoping that someone with experience in the area will offer something brilliant!
NOTE: I know that I can not get rid of the warning about insecure elements - it is there for a reason. I am just wondering if anyone else has experience in this area and has a reasonable compromise or some new insight.
Not sure how feasable this is but it may be possible to use a rewrite or proxy module to mirror the (img directory) structure on each clone to that of the central. With such a rule in place you could use relative img urls instead & internally rewrite all requests to these images over to the central server, silently
e.g.:
https://cloneA/banner.jpg -> http://central/static/banner.jpg
https://cloneB/topic7/img/header.jpg -> http://central/static/topic7/header.jpg
I'd go with B.
Sadly, I think you'll find this is a sad fact of life in SSL. Even if you were to put a cert on the other server, I think it may still get confused because of different sites [can't confirm nor deny though], and regardless, you don't want to waste the time of your media server by encrypting images.
I figured out a completely different way to import the images late last night after asking this question. In IIS, at least, you can set up "Virtual Directories" that can point essentially anywhere (I'm now evaluating whether to use a dedicated directory on each web server or a URL). If I use a dedicated directory on each server I will have three directories to keep up to date, but at least I don't have 70+.
Since each site will pull the images using resource locations found on the local site, then I don't have to worry about changing the SSL status of any page.
We are trying to streamline the process of showing clients their websites whilst in development without the need to change absolute paths etc.
We mostly develop locally and change our hosts files to reflect the domain name, when we are ready to show the client we copy the files to www.client.com/dev but I'm looking for a better method, any suggestions that can make this process smoother and faster would be great.
If you always host the site on a separate domain and not in a subdirectory, you will never have to change absolute paths. So instead of hosting a site in development at www.client.com/dev try dev.client.com. Another option would be to use client.yourcompany.com.
Also try to protect the site in development with HTTP basic authentication. This is easy to set up in most web servers, without changing your web application. Also, if the content is even remotely sensitive in any way, use HTTPS as well.
Alternatively, let them simply come over to your office and present it to them (or go to them and present it). The upside is that you have full control over what they will and won't see, and it never has to go online.
Well, we have client.t.uw.ru site which is universally visible.
When it matures, it moves onto www.client.com and is pushed to search engines.
Thus, we have a * DNS entry on t.uw.ru domain which makes it easy.
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!