Removing URL that isn't responding any more

[jeapostrophe]

No description provided.

[samth]

https://www.yahoo.com definitely responds for me (and usually for the DrDr machine).

[jeapostrophe]

It (and only it) regularly fails and produces false negatives in the testing, right?

…

On Sat, Oct 28, 2017 at 8:02 PM, Sam Tobin-Hochstadt < ***@***.***> wrote: https://www.yahoo.com definitely responds for me (and usually for the DrDr machine). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOM-oM-PuTiDH-fhhyMY0oDUoMkQdboks5sw8B5gaJpZM4QJ6S1> .

-- -=[ Jay McCarthy http://jeapostrophe.github.io ]=- -=[ Associate Professor PLT @ CS @ UMass Lowell ]=- -=[ Moses 1:33: And worlds without number have I created; ]=-

[samth]

Yes. I suspect that just retrying a couple times would be sufficient, but removing it seems ok too.

[greghendershott]

I don't think I've ever seen the Yahoo test fail when run locally -- or from Travis CI.

One idea just popped into my head: I could try adding a User-Agent request header with a value like "racket" -- or even the value from a popular browser.

Rationale: Maybe yahoo.com has some sort of throttling for "anonymous" requests. Maybe it does not kick in for requests from a whitelist and Travis CI is on that list. Just a hunch.

Or I could just skip that and merge the PR as-is.