Spot on - that works great - thanks!
On 7 April 2017 at 16:01, Gustaf Neumann wrote:
> Hi David,
>
> thanks for testing!
> I think, i have fixed the problem with:
>
> https://bitbucket.org/naviserver/naviserver/commits/
> 221d0c8f629bb29235e156a781ca5599284c3e9d
>
> The bug was a problem in
Hi David,
thanks for testing!
I think, i have fixed the problem with:
https://bitbucket.org/naviserver/naviserver/commits/221d0c8f629bb29235e156a781ca5599284c3e9d
The bug was a problem in nsssl triggered by "ns_connchan close".
The same verison of revproxy should work.
all the best
-g
Am 06.
Hi Gustaf,
I can confirm that if I switch to using http (rather than https) then your
timeout modification works perfectly.
So looking like it's (at least) ssl specific,
On 5 April 2017 at 18:03, Gustaf Neumann wrote:
> Am 05.04.17 um 18:45 schrieb David Osborne:
> > So although the timeout has
Am 05.04.17 um 18:45 schrieb David Osborne:
> So although the timeout has occurred in the proxy code, the connection
> appears to still have to wait for the backend to close the connection
> before continuing.
on my test setup, everything is closed correctly. this is either
ssl-specific, or linu
Thanks very much.
That's similar to what I was trying (although I was setting the timeout for
the backendReply callback only since it should be the first thing to be
called on reply if I understand rightly).
I get the same behaviour with your code.
Say I request a backend URL that takes 10 second
Dear David
I haven't tested connection creation timeouts. Only the situation
where the backend accepts the connection but takes a long time to
respond.
(My testcase is a backend URL which just does "ns_sleep 10")
It is an https backend. Running naviserver 4.99.16d4. Debian 8.6 with
kernel
On 2 April 2017 at 12:00, Gustaf Neumann wrote:
> Just to be sure: timeouts during connection creation work fine, but read
> timeouts from the back-end lead to the problem. ... and this happened with
> an https backend. And you are experiencing this under Linux. Did i
> understand this correctly?
Just to be sure: timeouts during connection creation work fine, but read
timeouts from the back-end lead to the problem. ... and this happened
with an https backend. And you are experiencing this under Linux. Did i
understand this correctly?
actually, ns_connchan has no own timeout semantics,
Hi,
I've been trying to get revproxy to work with a timeout. So if the backend
doesn't reply within $timeout secs, then the connection is closed.
What I thought we could do was set a timeout when creating the callback to
call backendReply.
Then when the callback is triggered with $when eq "t" we
