Hi Willy, I am sorry I have to reopen my inquiry:
> http-pretend-keepalive + http-close seemed to do the trick for GET Requests, yet when POSTing I still see the attached errors on the actual server machine, and the client seems to stall. (if this exceeds community support please let us know) :-) Thanks and kind regards from Lake Constance Michael > 2012-11-01 11:25:46,874 ERROR [de.betterform.agent.web.filter.XFormsFilter] : > org.mortbay.jetty.EofException > de.betterform.xml.xforms.exception.XFormsException: > org.mortbay.jetty.EofException > at > de.betterform.agent.web.WebProcessor.handleRequest(WebProcessor.java:396) > at > de.betterform.agent.web.filter.XFormsFilter.doFilter(XFormsFilter.java:209) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:326) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) > Caused by: org.mortbay.jetty.EofException > at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:791) > at > org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:569) > at > org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:1012) > at > org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:651) > at > org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:591) > at > de.betterform.agent.web.WebProcessor.handleRequest(WebProcessor.java:392) > ... 18 more > Caused by: java.io.IOException: Connection reset by peer > at sun.nio.ch.FileDispatcher.writev0(Native Method) > at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:33) > at sun.nio.ch.IOUtil.write(IOUtil.java:164) > at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:365) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:388) > at java.nio.channels.SocketChannel.write(SocketChannel.java:360) > at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:233) > at > org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:211) > at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:714) > ... 23 more Am 01.11.2012 um 11:12 schrieb Michael Seiferle <[email protected]>: > Hi Willy, > > thanks a lot for your help; unfortunately this did not do the trick yet. But: > …good news… > I additionally added: > http-pretend-keepalive > and *this* in conjunction with http-server-close seemed to do the trick, > though I admit, that I do not know why this combination exactly did it. > > Thanks a bunch! > I sent you an email off-list with links to a live example, I guess this could > be ignored for the moment and I will continue testing and let you know in > case we need further assitance! > > Best > Michael > > > > > Am 31.10.2012 um 23:04 schrieb Willy Tarreau <[email protected]>: > >> Hello Michael, >> >> On Wed, Oct 31, 2012 at 10:05:48AM +0100, Michael Seiferle wrote: >> (...) >>> We have a customer installation where only 32bit JVMs can be run, hence we >>> are spawning n instances of the same application on n different ports: >>> >>> target-machine:8766 >>> target-machine:8767 >>> target-machine:8768 >>> target-machine:8769 >>> >>> And we do have a balancer running on a dedicated `balancer` machine. >>> The clients *have* to be balanced based on IP (a legacy issue of the >>> software we use). >>> >>> Now we come to the ugly part: the application we intend to use, relies on >>> the >>> `HTTP Host` header field, as some operations cause it to send an internal >>> request. >>> In our current setup this internal request goes to the load balancer, which >>> in turn sends it to one of the target machines, but necessarily to the >>> target >>> machine it originated from. >> >> Indeed this is quite a ugly part, because it means that this application >> will never support virtual hosting, which has been the standard in the >> HTTP world for the last 10+ years. >> >> (...) >>> The directive adds the right server name to the header, but it seems to >>> mess with the proxied requests as jetty closes the streams prematurely and >>> throws `org.mortbay.jetty.EofException` as well as . >>> What I need is a Host header like: >>> >>> Host: target-machine:8766 >>> >>> instead of >>> >>> Host: balancer:8181 >> >> I have checked your config and I'm sure the issue is caused by the lack >> of "option http-server-close". This causes haproxy to only apply the >> change to the first request in a connection, so the second and next >> requests hold the original Host header again. Please add that option >> to your config and it should fix the problem. >> >> Regards, >> Willy >> >
