help with a multi process http server.

[Dave Cragg]

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