serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Kaufman <jef...@google.com.INVALID>
Subject Re: Spin when fetching resources over SSL
Date Wed, 28 Oct 2015 12:41:00 GMT
On Tue, Oct 27, 2015 at 7:10 PM, Bert Huijben <bert@qqmail.nl> wrote:
>
> What error is '11' for you? APR_EAGAIN?

11 is EAGAIN, yes.

>
> Or perhaps APR_EOF like in your previous report?

As in the previous report, when it finally times out I get:

2015-10-28T08:21:20.499352-04 DEBUG
[l:2620:0:1004:2:6c57:4dc:8e89:3aea:39286
r:2607:f8b0:4006:808::1012:443]
third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c:
ssl_decrypt: 70014 0
E1028 08:21:20.499403   28398 google_message_handler.cc:59] Serf
status 120108(APR does not understand this error code) polling for 1
threaded fetches for 0.05 seconds
2015-10-28T08:21:20.550097-04 DEBUG
[l:2620:0:1004:2:6c57:4dc:8e89:3aea:39286
r:2607:f8b0:4006:808::1012:443]
third_party/instaweb/src/third_party/serf/instaweb_outgoing.c: closed
socket, status 0

The 70014 is APR_EOF.

The 120108 is "The server unexpectedly closed the connection
prematurely", or SERF_ERROR_ABORTED_CONNECTION.

> (Completely different error range than the errors you reported last time)

I'm pretty sure these are the same errors I got last time.  Within the
spinning section I get 11 (EAGAIN) repeatedly, when it's all done I
get 70014 (APR_EOF) and 120108 (SERF_ERROR_ABORTED_CONNECTION).

>
> I'm surprised that I don't see familiar filenames; are you just running the normal serf
context loop? Or is it completely embedded in something else with its own event handling?
>

I'm invoking serf from a wrapper class in mod_pagespeed,
SerfUrlAsyncFetcher, but serf still has it's own context loop.

The filenames are slightly different (instaweb_foo instead of foo)
because we need to make some changes to get it to compile in our
system, like removing unused variables.

>
> Did you try the serf_get test tool against that same server and check how that responded?
> I think you can enable its logging by simply passing -d.

I haven't tried that; I'll check.

>
> Those hosts in your log appear to be one of the many www.google.com addresses; I have
no problem connecting to those using serf.
> (Testing: $ serf_get -d -H https://216.58.219.228/ )

These logs are from connecting to "https//www.google.com", but I get
this on all the other https addresses I've tried as well.
https://www.example.com https://https.cio.gov/
https://en.wikipedia.org/wiki/HTTPS
https://www.eff.org/https-everywhere

> Looking a bit further I see that the result on this host is a 301 redirect response,
forwarding to
>    http://www.google.com:443/
> Which is probably not a good url to test against. (I don't think port 443 allows plain
http :-)

Weird things happen if you don't give the host header.  Among other
things, https://216.58.219.228/  should fail the certificate check.

>
> Looping on APR_EAGAIN for every few bytes during the ssl handshake is not that uncommon...
you should see bigger chunks later in the connection. As Serf doesn't block the connection
many logged ssl errors with EAGAIN status are fairly common, but the only thing they tell
you is that your CPU is faster than your network connection to the server.
>

I see.  Some looping here makes sense.  What I'm seeing, though, is
many seconds of looping followed by serf reporting a fetch failure.

Mime
View raw message