PR #490 but for develop

[drdrew42]

I have been running into sporadic issues with AskSage problems. They seemed to randomly fail when trying to connect to the Sage Cell Server.

It turns out the response header gives plenty of opportunity to match "100":

checking for header:  HTTP/2 200 
date: Fri, 17 Jul 2020 16:51:30 GMT
content-type: application/json; charset=UTF-8
content-length: 437
set-cookie: __cfduid=dc7f19b456d5fb97ea5fbf50f3f71c4fa1595004689; expires=Sun, 16-Aug-20 16:51:29 GMT; path=/; domain=.sagemath.org; HttpOnly; SameSite=Lax
vary: Accept-Encoding
cf-cache-status: DYNAMIC
cf-request-id: 03ff493591000074018d33d200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5b4577cf49197401-IAD at /Users/drdrew42/mojo/renderv2/lib/RenderApp/Controller/../../PG/lib/WeBWorK/PG/IO.pm line 327

So, I've tightened up the regex matching for the header to more accurately identify HTTP 100 and HTTP 200 responses.

[drgrice1]

This looks good. It certainly is quite likely that the cf-request-id would mess up the check in the current code. In my testing that is the primary culprit, but it seems that the cookie and cf-ray could do it also. In any case, there is definitely plenty of opportunity for an incorrect match. I saw this occur frequently in my initial testing with the current code, and the updated regular expression check fixes it. It was clearly a problem checking the entire header block for a 100 or 200. The new regexp restricts a match to a single line of the header block.

It seems that the query_sage_server subroutine could use some clean up. There is some cruft in there that makes reading the code a bit confusing. Lines 366, 367, 369, 382, and 383 should be deleted. They seem to be left over from some earlier removed approach, and aren't used or meaningful.

[taniwallach]

Tested and it fixes the reported issues. More details in the discussion at #490 which is a hotfix to master (currently WW 2.15).