Wacky IE Problem
brad at danga.com
Wed Oct 19 09:09:35 PDT 2005
Oh, shit, I'd made a 1.38 release but never actually released it, it'd
I'll get to that today.....
On Wed, 19 Oct 2005, Kevin Lewandowski wrote:
> I've had the same problem. You need to update to the latest CVS
> version. That should fix it.
> On Oct 19, 2005, at 4:57 AM, Martin Atkins wrote:
> > Hi folks,
> > I've been having a problem that I'm finding quite hard to debug. I
> > have Perlbal deployed at my office in a selector/reverse-proxy
> > setup which proxies back to a different host depending on the Host
> > header. This has been working fine for a couple of months now, but
> > a few days ago we encountered a very bizarre problem.
> > One of the servers behind the proxy is a demo of a project we're
> > working on. One of the pages it returns contains a large HTML table.
> > When making the request for this page in Internet Explorer through
> > Perlbal, IE recieves most of the response but then suddenly and
> > inexplicably switches to either a "Page cannot be displayed" or a
> > "Page has expired" error. Which error gets displayed seems to be
> > random. Since it happens part-way through the response, my first
> > instinct was that it was a client-side problem.
> > However, making that same request using IE on our LAN here directly
> > to the server does not show the same problem. Also, arranging for
> > our router to translate a port to the server directly and making a
> > request to that from outside the network using IE does not show the
> > problem. We have two servers running the application here and the
> > problem occurs regardless of which one Perlbal is pointing at. It
> > seems that Perlbal is at least a factor if not the direct cause.
> > I did some packet sniffing and noticed a load of RST packets being
> > generated as the requests end, and recalled a post Brad made in his
> > journal a while back about that issue. I hacked Perlbal::Socket to
> > set the SO_LINGER flag on the socket and that caused the torrent of
> > RST to go away but does not solve the problem. The packet sniff
> > shows that the data is transmitted in its entirety.
> > Just to make it all the more bizarre, the problem seems to occur
> > regardless of the size of the response, except in some cases where
> > the number of columns in our table is less than a certain number.
> > If it stays below that number of columns, it can return as many
> > rows as it likes (within reason) and work just fine. However, this
> > might just be random dumb luck since it works occasionally anyway.
> > I'm completely at a loss. This problem is so completely off-the-
> > wall I don't know where to start! Any ideas? :)
> > We're running Perlbal 1.37.
More information about the perlbal