I looked at this really quickly, it wasn't my first 2 guesses, but here's a workaround for which I can't immediately say why it works (and something else odd might also be going on with that site)...

The cause seems to be that the site is extremely sensitive to the HTTP request headers (*not* the usual anti-bot/anti-abuse User-Agent header alone, nor the usual blocking of Tor US exit node IP addresses).

This worked for me (copying headers that worked in Tor Browser, using the Firefox Web developer tools that you usually get by pressing F12); I have not narrowed it down further:

(get-pure-port (string->url url)
                         (list "User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"                                "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
                               "Accept-Language: en-US,en;q=0.5"
                               "Accept-Encoding: gzip, deflate, br"
                               "Connection: keep-alive"
                               "Upgrade-Insecure-Requests: 1"
                               "Cache-Control: max-age=0"))))

The reason for the extreme header sensitivity might be anti-bot/abuse fingerprinting, or a strange Web programming bug, or some buggy server-side proxying/'firewall'/routing, or something else.

(BTW, something else odd might be going on with that site. Specifically, on a successful request, the Firefox built-in developer tools see only the one request and response (no redirect), of MIME type `text/plain`, *but* my custom uBlock Origin ruleset is blocking two additional requests, for scripts and fonts, which I wouldn't expect to be attempted at all from a single request and `text/plain` response (maybe it's a favico request?).  This is probably nothing, and I don't have time to investigate it right now, but a super-vigilant cybersecurity person couldn't help but start to consider threat models for users of that site (e.g., government users, big/strategic companies, activists).  If you were curious, debugging HTTPS traffic is a pain when you're not sure you can trust the browser, but one could copy the key from the browser, and capture the traffic with something like Wireshark or tcpdump, and see what's going on.  I kinda regret visiting it, and will try to forget it. :)

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to