On 22 Jan 2007, at 19:25, Andre Garzia wrote:
Suppose the scheduler is running 8080 and each server instance in
the pool is running from 8081 onwards. When the client connects to
8080, the scheduler sends back a redirection response so that the
client refreshes to a different port (of a free instance in the
pool). The problem is that a http client such as a browser will
then request favico and all the links in the html from the same
port for it re-uses data from the connection that yielded that
result to fill missing data in the URL. For example, if you make a
link that goes to /newpage.html, then the server will make it
http://yourserver/newpage.html. If I answered from port 8081, all
links in the page will "inherit" that port and I want all the
connections to come to the scheduler running on a different port.
One approach to solve this is to parse all the response and change
all the html responses to include the correct URLs. This is very
boring and slow for we must cope with href, src, link, rel and all
kinds of css includes and stuff. What I hoped to find was some HTTP
header field that would tell like: "hey this server is acutally
running at port bla bla bla" such as:
host: localhost:8080
despite the fact that that answer came thru 8081. This way the
whole thing would work and maybe we would have a a web server built
with Rev that could see some real world use...
Anyone has two cents?
This is very interesting, Andre. I wish I had your energy.
One thought.
If I understand correctly, under this system, the scheduler
immediately responds to the client with a redirect to the same url
but on a different port. Intead of using a redirect, is it not
possible for the scheduler to hand off the request directly to an
available process (for example, on localhost:8082), wait for the
response, and then the scheduler writes the response directly back to
the client? This would preserve the socket details for the client.
This would put an extra burden on the scheduler when it has to write
back large quantities of data to simulataneous requests from
different clients. But I think it should be possible to slice up the
responses so that you only write back to the client sockets in small
chunks (say 4096 KB at a time). This should allow simultaneous
connections to appear to work simultaneously.
Also, is there not a problem in redirecting clients that have made a
POST request? My memory of the http rfc is that redirects only use
the GET method. The above idea would get round that problem.
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
