Apart from the answers already provided by Chuck and Christopher, I wonder if a FAQ about
"proxying", "URL abstraction", "forwarding", "redirecting" etc.. and their differences
would not be useful ?
This kind of question seems to come so often that it would save time in the end if there
was just a link to point to.
Quick and dirty :
- a "redirect" is when the server sends a HTTP response to the browser saying "sorry, the
URL you requested is wrong, but the right one is *here* (with the correct URL).
The browser then (without even informing the user) immediately makes a new request to this
new URL.
Hint : the browser's URL bar, in that case, will show the new URL.
Advantage : the browser will also discard the old URL from its cache and history, and
cache the new one instead. The user may even notice, and request the correct URL right
away the next time.
Inconvenient : there is more traffic, because there is one request/response exchange for
nothing (original request -> 302 response from server -> new request from browser ->
server response to "correct" request)
- a "forward" (and also the concept of "URL abstraction") is when the server silently
rewrites the URL requested by the user, so that it will be processed by a different webapp
(or return a different static document) than the one that would appear to be implied by
the original request URL.
Hint : none, because the browser will think that the response comes for his original
request URL.
Advantage : there is no extra network traffic, and it is faster (at least for the client),
because it all remains internal to the server.
Inconvenient : the browser (and user) remain "stupid", in the sense that they will
continue to use the original URL, thinking it is correct.
(This may actually not be an inconvenient, if this is what the server admin
wants)
- a "proxy" is when the server receives a request for a URL which appears "local", but
then silently behind the scene calls another server to provide the response.
The original server then reads the response from the background server and returns it to
the client as if it had made it up himself.
Advantages/Inconvenients : a bit vast to discuss here, but this is the basic mechanism for
something like load-balancing : a front-end server (with a single access point for the
clients) receives all requests, and intelligently distributes them to a number of
background servers, in function of the load, the type of request, or whatever.
The client keeps thinking that the responses come from the front-end server, so it keeps
talking to the front-end.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
