Dave,
I didn't want to add that burden to the scheduler because I am afraid
of denial of service, my whole quest in the field of revolution based
servers is trying to avoid such situations. I need to check if I can
redirect POST requests... If I can't then I'll need to implement a
solution like you outlined here at least for POST calls.
If I managed to build such thing, I'll post here on the list.
Cheers
andre
On Jan 22, 2007, at 6:18 PM, Dave Cragg wrote:
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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
