racket url connection problem solved by reboot?

['John Clements' via users-redirect]

This may be an OS question, but it manifested as a curious racket problem, so I thought I’d ask. Consider the following program:

#lang racket

(require net/url)

(post-impure-port
(string->url "http://brinckerhoff.org:8025/")
#"request=1234"
'("Content-Type: application/x-www-form-urlencoded”))

Basically, just open a connection to a web server. The observed and reproducible behavior when running in DrRacket 7.4.0.1 was that there was a 77-second delay, and then the port was opened just fine. Looking at the back end (this was a connection to a racket web server, perhaps unfortunately), there was no evidence of a connection until the 77 seconds was up.

Contacting the given URL (http://brinckerhoff.org:8025/) with a web browser (Firefox), though, produced a near-instantaneous response—about 2 seconds.

I saw the same delay when running the program using ‘racket’ at the command-line.

I then rebooted my machine (MacOS Mojave 10.14.6). The problem went away.

In retrospect, I regret rebooting before doing more experimentation; does this apply to other versions of Racket? Other ways of connecting?

So, it looks like both DrRacket and Racket were experiencing some kind of persistent OS-related network block. All the (mumble)s were taken? But then, why did the web browser go through? Perhaps the web browser has some deeper knowledge of the OS that allows it to detect and work around this problem.

Can anyone shed any light on whether this is
a) a known issue with the operating system,
b) a misunderstanding on my part, or
b) a bug/problem with Racket?

Many thanks,

John

['John Clements' via users-redirect]

Oh! both excellent thoughts. Okay, I’ll try to remember this for the next time this happens.

Many thanks!

John


> On Aug 19, 2019, at 11:10, Bogdan Popa <bog...@matchacha.ro> wrote:
>
> The server doesn't seem to handle `Expect:' headers properly so, for
> example, curl has a couple seconds' delay when you run the following
> from the command line:
>
> $ curl -v -F'request=1234' brinckerhoff.org:8025
>
> * Rebuilt URL to: brinckerhoff.org:8025/
> * Trying 45.79.98.233...
> * TCP_NODELAY set
> * Connected to brinckerhoff.org (45.79.98.233) port 8025 (#0)
>> POST / HTTP/1.1
>> Host: brinckerhoff.org:8025
>> User-Agent: curl/7.54.0
>> Accept: */*
>> Content-Length: 146
>> Expect: 100-continue
>> Content-Type: multipart/form-data; boundary=------------------------94d1720a98a20d42
>>
> * Done waiting for 100-continue
> < HTTP/1.1 200 Okay
> ...
>
> Here's the output when you disable the Expect header:
>
> $ curl -H'Expect:' -v -F'request=1234' brinckerhoff.org:8025
>
> * Rebuilt URL to: brinckerhoff.org:8025/
> * Trying 45.79.98.233...
> * TCP_NODELAY set
> * Connected to brinckerhoff.org (45.79.98.233) port 8025 (#0)
>> POST / HTTP/1.1
>> Host: brinckerhoff.org:8025
>> User-Agent: curl/7.54.0
>> Accept: */*
>> Content-Length: 146
>> Content-Type: multipart/form-data; boundary=------------------------f6089861efe4775a
>>
> < HTTP/1.1 200 Okay
>
> (no delay before the response is returned)
>
> Maybe `post-impure-port' sends an `Expect' header on POST and tries to
> handle the exchange correctly? IIRC, web browsers don't send `Expect'
> headers.
>
> The other explanation could be related to DNS resolution. Do you run
> `dnsmasq' or something like it locally? I've run into slow DNS
> resolution issues myself on macOS when my resolvers were misconfigured.
> These tend to lead to heisenbugs when the slow resolution eventually
> resolves and gets cached so all subsequent calls are fast.