Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
On Fri, Aug 05, 2005 at 06:33:25AM -0400, Jason Harris wrote: > On Thu, Aug 04, 2005 at 07:54:09AM -0400, David Shaw wrote: > > On Thu, Aug 04, 2005 at 12:24:27AM -0400, Jason Harris wrote: > > > > 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 > > Disregard that. > > It isn't the Expect: header, it was the [s]scanf. This patch fixes it: Excellent. Thanks, Jason. I'm glad these little details are getting fixed before the next GnuPG which uses curl by default. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
On Thu, Aug 04, 2005 at 07:54:09AM -0400, David Shaw wrote: > On Thu, Aug 04, 2005 at 12:24:27AM -0400, Jason Harris wrote: > > 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 Disregard that. It isn't the Expect: header, it was the [s]scanf. This patch fixes it: diff -u -r1.5 dbserver.ml --- dbserver.ml +++ dbserver.ml @@ -415,8 +415,9 @@ let request = Wserver.strip request in match request with "/pks/add" -> - let keytext = Scanf.sscanf body "keytext=%s" (fun s -> s) in + let keytext = Scanf.sscanf body "keytext%s" (fun s -> s) in let keytext = Wserver.decode keytext in + let keytext = Str.string_after keytext 1 in let keys = Armor.decode_pubkey keytext in plerror 3 "Handling /pks/add for %d keys" (List.length keys); -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? [EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 pgpIDzPHesXTN.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
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 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
SKS v. unknown HTTP headers (was: Re: IPv6 failover?)
On Wed, Aug 03, 2005 at 08:44:18PM -0400, David Shaw wrote:
> On Wed, Aug 03, 2005 at 08:18:35PM -0400, Jason Harris wrote:
> > Looking at http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ,
> > this might do the trick:
> >
> > curl_easy_setopt (..., CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);
> >
> > if any connection, which always seems to prefer IPv6, doesn't
> > at first succeed.
>
> I'm not sure. CURL_IPRESOLVE_V4 is documented to force the connection
> to IPv4. That is, it'll ignore IPv6 addresses altogether, rather than
> try to connect and then fail over within curl. What happens if you
> add a "-4" to the command line above? That sets CURL_IPRESOLVE_V4.
(That works fine, of course.)
> 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 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).
--
Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
[EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/
Got photons? (TM), (C) 2004
pgp83RiibzDZH.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
