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 62.94.26.10... * connected > * Connected to keyserver.linux.it (62.94.26.10) 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 > issue. > > 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. David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users