SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
dshaw at jabberwocky.com
Thu Aug 4 13:54:09 CEST 2005
On Thu, Aug 04, 2005 at 12:24:27AM -0400, Jason Harris wrote:
> > Also, going back to the original problem, can you send me the output
> > when you try fetching a key with "--keyserver-options debug" set?
> OK, with --recv I see it falls back from v6 to v4, which is good, but it
> fails with --send:
> %gpg --keyserver-options debug --keyserver keyserver.linux.it --send ...
> gpg: sending key ... to hkp server keyserver.linux.it
> Host: keyserver.linux.it
> Command: SEND
> gpgkeys: HTTP URL is `http://keyserver.linux.it:11371/pks/add'
> * About to connect() to keyserver.linux.it port 11371
> * Trying 2001:1418:13:10::1... * Failed to connect to 2001:1418:13:10::1: No route to host
> * Undefined error: 0
> * Trying 188.8.131.52... * connected
> * Connected to keyserver.linux.it (184.108.40.206) port 11371
> > POST /pks/add HTTP/1.1
> Host: keyserver.linux.it:11371
> Accept: */*
> Content-Length: 2246
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
> < HTTP/1.1 100 Continue
> * The requested URL returned error: 500
> * Closing connection #0
> gpgkeys: HTTP post error 22: Failed to connect to 2001:1418:13:10::1: No route to host
> However, this seems to be specific to SKS. My SKS log reports:
> 2005-08-04 ... ... Error handling request (POST,/pks/add,[+accept:*/*+content-length:2246+content-type:application/x-www-form-urlencoded+expect:100-continue+host:skylane.kjsl.com:21371]): Scanf.Scan_failure("scanf: bad input at char number 8: looking for =, found %")
> so the connection is being made (in this case via IPv4; skylane also has
> an AAAA record). Moreover, the error messages from curl are confusing this
> Thus, in reality, the "Expect: 100-continue" header appears to be confusing
> SKS (during POSTs).
Hmm. No really good way to fix that in GPG or curl since they can't
detect that a server is 1.0 without doing a GET first. Curl, if I
recall, can correctly handle the case when the Continue header is not
supplied (it gives up after a while).
The problem here seems to need a SKS fix. SKS needs to ignore HTTP
headers that it doesn't understand. That's HTTP, anyway.
Terribly misleading error message from curl there.
More information about the Gnupg-users