On Wednesday 08 May 2013 20:31:38 David Strauss wrote:
> On Wed, May 8, 2013 at 11:29 AM, David Strauss
wrote:
> > which I think it is now
>
> I'm referring to very recent releases here, not "now" as in current
> Fedora packages.
It is already fixed in rawhide and I will submit update with fixe
On Wednesday 08 May 2013 14:15:22 Daniel Stenberg wrote:
> On Wed, 8 May 2013, Kamil Dudka wrote:
> > So are the NSS recv/send functions. Only the handshake still blocks with
> > NSS. I guess that David needs the following fix:
> >
> > https://github.com/bagder/curl/commit/9d0af301
>
> Ah yes, th
On Wed, May 8, 2013 at 11:37 AM, David Strauss wrote:
> Does it at least time out based on the configured libcurl connection or
> request timeout?
Read some source and found the answer: yes.
timeout = PR_MillisecondsToInterval((PRUint32) time_left);
/* Force the handshake now */
if(SSL_
On Wed, May 8, 2013 at 5:01 AM, Kamil Dudka wrote:
> Only the handshake still blocks with NSS.
Is there a way to fix this, too? Does it at least time out based on
the configured libcurl connection or request timeout?
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
On Wed, May 8, 2013 at 11:29 AM, David Strauss wrote:
> which I think it is now
I'm referring to very recent releases here, not "now" as in current
Fedora packages.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
On Wed, May 8, 2013 at 5:15 AM, Daniel Stenberg wrote:
> But don't you also agree that PR_INTERVAL_NO_WAIT is more suitable than -1
> for the PR_Recv timeout parameter?
Summarizing my RHBZ comment [1], the timeout value seems completely
unused in the main send and receive functions if the non-blo
On Wed, 8 May 2013, Kamil Dudka wrote:
So are the NSS recv/send functions. Only the handshake still blocks with
NSS. I guess that David needs the following fix:
https://github.com/bagder/curl/commit/9d0af301
Ah yes, that might be it.
But don't you also agree that PR_INTERVAL_NO_WAIT is mor
On Tuesday, May 07, 2013 23:44:12 Daniel Stenberg wrote:
> On Tue, 7 May 2013, David Strauss wrote:
> >> What about using PR_INTERVAL_NO_WAIT instead of -1?
> >
> > I'm not sure there's a way for that to work efficiently without waiting
> > for
> > an event from NSS, if that's possible.
>
> That'
My rebuild the Fedora 17 curl and libcurl packages works fine with the
timeout=PR_INTERVAL_NO_WAIT value. All test pass, and I don't see any
issues using the curl CLI with HTTPS.
I'll have to run some more extensive experiments to verify if the
timeout is working for NSS now.
On Tue, May 7, 2013
On Tue, May 7, 2013 at 2:49 PM, Daniel Stenberg wrote:
> Assuming it actually makes any difference for your case at least! ;-)
If it means that it respects the timeouts we give, it's absolutely a
fix for the problem we see.
I've posted this to Red Hat/Fedora Bugzilla to request a backport of
the
On Tue, 7 May 2013, David Strauss wrote:
What about using PR_INTERVAL_NO_WAIT instead of -1?
I'm not sure there's a way for that to work efficiently without waiting for
an event from NSS, if that's possible.
That's already done before the function is called in the first place. The
the GnuT
On Tue, 7 May 2013, David Strauss wrote:
Well, then that sounds perfect!
Assuming it actually makes any difference for your case at least! ;-)
--
/ daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
E
On Tue, May 7, 2013 at 2:44 PM, Daniel Stenberg wrote:
> That's already done before the function is called in the first place. The
> the GnuTLS and OpenSSL versions of that function for example are completely
> non-blocking.
Well, then that sounds perfect!
--
David Strauss
| da...@davidstraus
On Tue, May 7, 2013 at 2:30 PM, Daniel Stenberg wrote:
> What about using PR_INTERVAL_NO_WAIT instead of -1?
I'm not sure there's a way for that to work efficiently without
waiting for an event from NSS, if that's possible.
Otherwise, it seems like it would be best to calculate the remaining
tim
On Tue, 7 May 2013, David Strauss wrote:
It looks like PR_Recv(conn->ssl[num].handle, buf, (int)buffersize, 0, -1) in
nss_recv() (nss.c) may be the problem. That sets the timeout for NSS to
4294967295.
What about using PR_INTERVAL_NO_WAIT instead of -1?
--
/ daniel.haxx.se
Here are the PR_Recv API docs [1]. Also, according to the
PRIntervalTime docs [2], it should be invoked with
PR_INTERVAL_NO_TIMEOUT for no timeout. PR_INTERVAL_NO_TIMEOUT is
equivalent to the current value of -1.
[1] https://developer.mozilla.org/en-US/docs/PR_Recv
[2] https://developer.mozilla.or
It looks like PR_Recv(conn->ssl[num].handle, buf, (int)buffersize, 0,
-1) in nss_recv() (nss.c) may be the problem. That sets the timeout
for NSS to 4294967295.
On Tue, May 7, 2013 at 1:57 PM, David Strauss wrote:
> On Tue, May 7, 2013 at 1:46 PM, David Strauss wrote:
>> NSS seems stuck in poll
This -1 timeout is also in the current master:
https://github.com/bagder/curl/blob/master/lib/nss.c#L1518
On Tue, May 7, 2013 at 2:11 PM, David Strauss wrote:
> It looks like PR_Recv(conn->ssl[num].handle, buf, (int)buffersize, 0,
> -1) in nss_recv() (nss.c) may be the problem. That sets the time
On Tue, May 7, 2013 at 1:46 PM, David Strauss wrote:
> NSS seems stuck in poll loop, which has been going on for hours
Actually, I'm not sure it's NSS stuck there. The loop could be higher
up. I just see an unending series of polls from strace.
--
David Strauss
| da...@davidstrauss.net
| +
19 matches
Mail list logo
