On Thu, May 23, 2002 at 08:30:54PM +0900, GOTO Kentaro wrote:> At Thu, 23 May 2002 12:12:18 +0200,> Lars Christensen wrote:> > > s.mount_proc("/"){|req, res|> > > res.body = "http://#{req['host']}#{req.request_uri}";> > > }> > > Thanks. This helped in the case of HTTP/1.1. However, in the case of HT=TP/1.0> > (or others) it could be useful to have access to the return value of> > Socket#addr of the local. This following patch adds this to the httpre=quest> > class.> > Thank you for patch. However, I'm sorry to say that looks having> problem because Socket#addr uses gethostname(2) simply. Generally> speaking, gethostname may differ from DNS record or /etc/hosts in the> LAN. So Socket#addr is not appropriate for the host part of URL.> > I looked for a platform independent way to get host name automatically> too, but there seems not existing.To me, this seems more like the problem of defining what HTTPRequest#locala=ddris garaunteed to do. I.e. using Socket#addr, it merely gets the ip, port orpossibly domain from the reverse lookup of the IP.In case of non-virtual host, using this should work in a subsequent request,unless the server's DNS records and /etc/hosts files are disagreeing on thenames of the host. On a virtual host, the client would supply the 'Host' header, which should =theninstead be used as in my example. I suppose this is true, also for HTTP/1.0= (?)> Then, I think default host part should be given manually by config or> something else.If you want to run the webrick server on multiple interfaces and take diffe=rentactions depending on which interface the request is made on, you would need= theSocket#addr information. The alternative, to start a server on each of theinterfaces seems to me a bit of overkill in, at least, my situtation.-- Lars Christensenattatchment (application/pgp-signature) ignored