Requests to fetch GitHub patch fails in SCL3



a year ago
a year ago


(Reporter: emceeaich, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


If a users links a GitHub pull request, splinter should fetch and display the patch.

This is failing in environments running in SCL3, but works in other environments. 

Is there a configuration missing that is blocking this.
dylan, kendall, can you guys take a look at this when you're back in the office?
Flags: needinfo?(klibby)
Flags: needinfo?(dylan)
Yep! I'll provide a script that does the same thing the web head does to help debug what is failing.
Flags: needinfo?(dylan)
I owe a script/test case
Flags: needinfo?(dylan)
NI me again when you've got the script and I'll look.

I see random github fetch errors in the logs (503 Service Unavailable), but I'm able to curl those URLs successfully, as well as the pages they 302 to.
Flags: needinfo?(klibby)
Hi, I'm escalating this bug somewhat. Theory is, this is failing due to the SCL3 proxy cluster refusing the requests, which is why running it manually works. I will invoke my IT access now to confirm/reject that.
Flags: needinfo?(dylan) → needinfo?(rsoderberg)
Proxy testing confirmed that the proxies permit these requests, but also found that curl -k can't follow the form of redirect used by Github - and neither can BMO.

n? :dylan to provide more details and the error message he saw.
Flags: needinfo?(rsoderberg) → needinfo?(dylan)
I mistested. curl can follow the redirect. Dylan suggested SNI, which could be the case:

$ openssl s_client -connect
 0 s:/businessCategory=Private Organization/ Colin P Kelly, Jr Street/postalCode=94107/C=US/ST=California/L=San Francisco/O=GitHub, Inc./

$ openssl s_client -connect -servername
 0 s:/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*
sorry it took so long to get this put together:

cd /data/www/
perl -Ilocal/lib/perl5 -MLWP::UserAgent -E 'my $ua = LWP::UserAgent->new; $ua->proxy("https", "http://squid.proxy.service.consul:3128/"); my $r = $ua->get(""); say $r->content'

result: <p>This proxy and the remote host failed to negotiate a mutually acceptable security settings for handling your request. It is possible that the remote host does not support secure connections, or the proxy is not satisfied with the host security credentials.</p>
Flags: needinfo?(dylan)
<p><b>Failed to establish a secure connection to</b></p>

<p id="sysmsg">The system returned: <i>(71) Protocol error</i></p>


You need to log in before you can comment on or make changes to this bug.