-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Wow, what a thorough analysis, thanks Phil. :) FWIW, I did see those Expect: headers you describe in my debug output, and obviously if this issue only affects certain servers it would explain why I was only seeing it intermittently.
I should have added before, I'm on Ubuntu 12.10, and gpg2 comes built with libcurl. Doug On 03/01/2013 12:04 AM, Phil Pennock wrote: | Short version: bad interaction of GnuPG, cURL and Apache. Can probably | be worked around in Apache config, can definitely be worked around in | GnuPG code, should aim to get both done. | | On 2013-02-28 at 10:01 -0800, Doug Barton wrote: |> 2001:470:1f09:5e7::2 worked |> 2001:470:1f0a:5d7::2 failed | |> In any case thanks for clarifying the cause of the error ... it's just |> hard to debug without putting those options in first obviously, and |> with those options the output is very noisy. | | 417 is not load-related, Kristian's goofed. | | 417 _only_ happens when the client sends "Expect: 100-continue", in an | HTTP/1.1 request, and a reverse proxy (or forward-proxy) knows that the | backend is HTTP/1.0 only. | | GnuPG will use such a header with a _POST_ request, ie when _sending_ | keys; that expectation is a POST optimisation, and it's coming from | cURL. | | In this case, the failing server is keys.wuschelpuschel.org, which is | running GnuKS behind Apache. Since SKS/GnuKS only support HTTP/1.0, | Apache has been "correctly" configured, per standards. nginx doesn't | support returning 417, so this is only seen with Apache-fronted | keyservers. | | I see nothing in RFC2616 which explains how 1.1 clients speaking to 1.1 | proxies with 1.0 origin servers should handle this. Presumably, they | should retry. | | Can someone running SKS/GnuKS behind Apache please use: | gpg -v --keyserver-options verbose,debug --keyserver THEIRS - --send-key WHATEVER | and confirm that they see this (as I do, reliably and reproducibly) and | then try: | | <IfModule mod_headers.c> | RequestHeader unset Expect early | </IfModule> | | I suspect that just ripping the header out of the request and pretending | it's not there will let things "work". | | | GnuPG developers: with GnuPG 2.0.19, in keyserver/gpgkeys_hkp.c main(), | around line 783, I added an empty "Expect:" header to force cURL to not | send that header, and it worked. I could then send a key to | keys.wuschelpuschel.org. | | ----------------------------8< cut here >8------------------------------ | headers=curl_slist_append(headers,"Pragma: no-cache"); | if(headers) | headers=curl_slist_append(headers,"Cache-Control: no-cache"); | /* Added this next bit: */ | if(headers) | headers=curl_slist_append(headers,"Expect:"); | ----------------------------8< cut here >8------------------------------ | | | So: I know GnuPG can work around it, that will take a while to work | around. If we can get someone using Apache to confirm that the above | fix works for them, we can push people to include it. | | Kristian: I suggest that a pool check might try an HTTP/1.1 POST with an | Expect: header and exclude from the main pools any server where this | fails. | | (Similarly, need to figure out what to do about nginx/FreeBSD/KQUEUE for | GnuPG curl-shim ... harder to deterministically detect. For myself, I | might suck it up and rebuild without KQUEUE support.) | | Regards, | -Phil | -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBCAAGBQJRMGsCAAoJEFzGhvEaGryEoDkH/jCg+lTVCRM0l1Gb+8LWcxhO 2Y2tZo4lL1ndjC+SA+VEpwvWk1j/nxmOM0/JuWYHOLJmHb2SbkCSCBh+zKmdFhUD WVam/1Or4yTMr81P5HTnkqXK7dtvO8WykAufYwtzCChDmgSur01D6s/hl2TJvE2/ tc312aUMoWaUQas/wwZxPaDDtuuuku0tDP66V38vWG/M/MPSR+m1SN9+1CgkJ9AA X4/YAFOacy1KaTVuGn92GDiSo/qAY34bf14U82RV90rPSY0YUPxlREQ6kRnFIlgS oYAapEOf2VfNSzCiYZ0PHl2MS35G1ca6i7FJJJQUWv9v4d27fTuc4CntwPYZliM= =7JXm -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
