I want my website to serve static contents by different server and if possible even javascripts files as well from another server. I know it can be achieved using url rewrites but it gives 301 errors (i.e. extra round trip to browser). I asked similar question here but did not get any satisfactory response as it seems my question was not correct.
Can some one suggest how to achieve this without extra round trip to browser? I have seen other teams achieving this in Apache server but not able to find how to do it in IIS.
Have you tried "Rewrite" instead of "Redirect"? These are at least two viable options of rewriting where Redirect means 301/302 and rewrite operates silently at the server.
From your other question, it seems that you tried with "Redirect", this explains the 301. Change Redirect to Rewrite then.
The only important thing is that if you want your rewrites act between different servers, you will need the ARR (Application Request Routing) installed on a front-end server. While URL Rewrite handles only local rewrites, ARR can act as a transparent proxy to other servers.
ARR is a free add-on to IIS
http://www.iis.net/downloads/microsoft/application-request-routing
Related
I am currently having issues with setting up an HTTPS domain redirect. I have a DNS URL redirect entry that points a few sub-domains to same-server URLs. For example:
docs.kipper-lang.org -> kipper-lang.org/docs/
play.kipper-lang.org -> kipper-lang.org/playground
The issue I am currently experiencing is that when using the subdomains, it mostly works, but it can only use HTTP. If I attempt to use HTTPS (like for example https://docs.kipper-lang.org) the redirect won't work and will get stuck apparently waiting for the HTTPS certificate (I think, but I don't know for sure, since it loads forever and gets a time-out).
So my DNS provider does its job for the most part as I want, but I am not sure how to add the HTTPS encryption to these redirects. Is there maybe even some DNS configuration or even middle-man service for redirects I can use, where these HTTPS encryptions are built-In? Since receiving a "Warning: Insecure connection" every time someone uses the sub-domains is a massive problem for me.
Note though that considering I am hosting on a GitHub Pages server, I am unable to do these redirects on the server side myself, as I can't use any code in this case.
I would greatly appreciate any ideas for fixing this or what I could use to achieve this another way.
Thanks in advance!
I am using schemeless urls for loading few external libraries.
//ajax.googleapis.com/ajax/libs/jquery.....
The problem i am facing is that few crawlers are treating them as relative urls
www.mydomain.com//ajax.googleapis.com/ajax/libs/jquery.....
How can i handle such links for crawlers.
I am using Nginx server but i am fairly new to Nginx.
is some kind of rewrite possible?
Your URL is actually valid, it's the crawler's fault for not handling this case while crawling, I would just ignore it.
Also the 404 response is also valid from your server, because the crawler is requesting www.example.com//ajax.googleapis.com/.. which really doesn't exist.
How does web server implements url rewrite mechanism and changes the address bar of browsers?
I'm not asking specific information to configure apache, nginx, lighthttpd or other!
I would like to know what kind of information is sent to clients when servers want rewrite url?
There are two types of behaviour.
One is rewrite, the other is redirect.
Rewrite
The server performs the substitution for itself, making a URL like http://example.org/my/beatuful/page be understood as http://example.org/index.php?page=my-beautiful-page
With rewrite, the client does not see anything and redirection is internal only. No URL changes in the browser, just the server understands it differently.
Redirect
The server detects that the address is not wanted by the server. http://example.org/page1 has moved to http://example.org/page2, so it tells the browser with an HTTP 3xx code what the new page is. The client then asks for this page instead. Therefore the address in the browser changes!
Process
The process remains the same and is well described by this diagram:
Remark Every rewrite/redirect triggers a new call to the rewrite rules (with exceptions IIRC)
RewriteCond %{REDIRECT_URL} !^$
RewriteRule .* - [L]
can become useful to stop loops. (Since it makes no rewrite when it has happened once already).
Are you talking about server-side rewrites (like Apache mod-rewrite)? For those, the address bar does not generally change (unless a redirection is performed).
Or are you talking about redirections? These are done by having the server respond with an HTTP code (301, 302 or 307) and the location in the HTTP header.
There are two forms of "URL rewrite": those done purely within the server and those that are redirections.
If it's purely within the server, it's an internal matter and only matters with respect to the dispatch mechanism implemented in the server. In Apache HTTPD, mod_rewrite can do this, for example.
If it's a redirection, a status code implying a redirection is sent in the response, along with a Location header indicating to which URL the browser should be redirected (this should be an absolute URL). mod_rewrite can also do this, with the [R] flag.
The status code is usually 302 (found), but it could be configured for other codes (e.g. 301 or 307).
Another quite common use (often unnoticed because it's usually on by default in Apache HTTPD) is the redirection to the the URL with a trailing slash on a directory. This is implemented by mod_dir:
A "trailing slash" redirect is issued
when the server receives a request for
a URL http://servername/foo/dirname
where dirname is a directory.
Directories require a trailing slash,
so mod_dir issues a redirect to
http://servername/foo/dirname/.
Jeff Atwood had a great post about this: http://www.codinghorror.com/blog/2007/02/url-rewriting-to-prevent-duplicate-urls.html
How web server implements url rewrite mechanism and changes the address bar of browsers?
URL rewriting and forwarding are two completely different things. A server has no control over your browser so it can't change the URL of your browser, but it can ask your browser to go to a different URL. When your browser gets a response from a server it's entirely up to your browser to determine what to do with that response: it can follow the redirect, ignore it or be really mean and spam the server until the server gives up. There is no "mechanism" that the server uses to change the address, it's simply a protocol (HTTP 1.1) that the server abides by when a particular resource has been moved to a different location, thus the 3xx responses.
URL rewriting can transform URLs purely on the server-side. This allows web application developers the ability to make web resources accessible from multiple URLs.
For example, the user might request http://www.example.com/product/123 but thanks to rewriting is actually served a resource from http://www.example.com/product?id=123. Note that, there is no need for the address displayed in the browser to change.
The address can be changed if so desired. For this, a similar mapping as above happens on the server, but rather than render the resource back to the client, the server sends a redirect (301 or 302 HTTP code) back to the client for the rewritten URL.
For the example above this might look like:
Client request
GET /product/123 HTTP/1.1
Host: www.example.com
Server response
HTTP/1.1 302 Found
Location: http://www.example.com/product?id=123
At this point, the browser will issue a new GET request for the URL in the Location header.
we have nearly 13 domains within our company and we would like to serve images from one application in order to leverage caching.
for example, we will have c1.example.com and we will put all of our product images under this application. but here I have some doubts;
1- how can I force client browser's to cache the image and do not request it again?
2- when I reference those images on my application, I will use following html markup;
<img scr="http://c1.example.com/core/img1.png" />
but this causes a problem when I run the website under https. It gives warning about the page. It should have been used https//c1.example.com/core/img1.png when I run my apps under https. what should I do here? should I always use https? or is there a way to switch between auto?
I will run my apps under IIS 7.
Yes you need to serve all resources over https when the html-page is served over https. Thats the whole point of using https.
If the hrefs are hardcoded in the html one solution could be to use a Response Filter that will parse all content sent to the client and replace http with https when necessary. A simple Regular Expression should do the trick. There are plenty of articles out there about how these filters are working.
About caching you need to send the correct cache-headers and etag. There are several of questions and answers on this on SO like this one IIS7 Cache-Control
You need to use HTTP headers to tell the browser how to cache. It should work by default (assuming you have no query string in your URLs) but if not, here's a knowledge base article about the cache-control header:
http://support.microsoft.com/kb/247404
I really don't know much about IIS, so I'm not sure if there are any other potential pitfalls. Note that browsers may still send HEAD requests sometimes.
I'd recommend you setup the image server so that HTTP/S is interchangeable, then just serve HTTPS Urls from HTTPS requests.
I have a site that is hosted in shared hosting environment. They use a wildcard subdomain setup and suggest using Response.Redirect to achieve the illusion of a subdomain.
Is there a way of doing this such that the "switch" takes place on the server rather than bouncing back down to the browser first?
Server.Transfer only works if I transfer to an actual resource. So redirecting from sub1.mydomain.com to www.mydomain.com/public/ does not work. I'd have to redirect to www.mydomain.com/public/mypage.aspx instead which i dont want to do.
To ensure that the "switch" takes place on the server, you could create a simple HTTP Module to intercept each request, inspect the requested URL and then forward them as needed . All your module has to do is handle the OnBeginRequest event, and then forward the request. In this way you could really have unlimited sub-domains.
Also might want add a blank host header, so that any requests for subdomains not listed get forwarded to the proper default website
If you aren't familiar with them, modules are very simple to create and work with.
Heres a link to a very similar implementation by Brendan Tompkins:
http://codebetter.com/blogs/brendan.tompkins/archive/2006/06/27/146875.aspx
You could also do some URL rewriting in the module should you need specific URL "look" behavior.