help with a multi process http server.

[Andre Garzia]

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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution