SKS v. unknown HTTP headers (was: Re: IPv6 failover?)

[David Shaw]

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