On 2012-12-05 at 23:32 -0500, David Shaw wrote: > It's working, it's just misleading since the SRV replacement happens > after the debug logging so the actual URL that is hit is not the one > that is being logged. If you look at netstat, you can see it's > connecting to the right port.
Sorry for the delay getting back to you. > Try this new patch (by itself, not on top of an earlier one) - it logs > before and after the SRV replacement so it's clear what is going on. Using Curl: So, I do see the correct port being used (bug 1446), I don't see the correct hostname (bug 1447) ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22 libssh2/1.4.1 librtmp/2.3 Host: keyserver.spodhuis.org Port: 11374 Command: GET * About to connect() to keyserver.spodhuis.org port 11374 (#0) * Trying 2a02:898:31:0:48:4558:73:6b73... * connected * Connected to keyserver.spodhuis.org (2a02:898:31:0:48:4558:73:6b73) port 11374 (#0) > GET /pks/lookup?op=get&options=mr&search=0x403043153903637F HTTP/1.1 Host: keyserver.spodhuis.org:11374 Accept: */* Pragma: no-cache Cache-Control: no-cache * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < Date: Fri, 07 Dec 2012 07:26:05 GMT < Content-Type: application/pgp-keys; charset=UTF-8 < Content-Length: 63475 < Connection: keep-alive < Server: sks_www/1.1.4 < Cache-Control: no-cache < Pragma: no-cache < Expires: 0 < X-HKP-Results-Count: 1 < Content-disposition: attachment; filename=gpgkey.asc < Via: 1.1 keyserver.spodhuis.org:11374 (nginx) < * Connection #0 to host keyserver.spodhuis.org left intact * Closing connection #0 [gpg output for key] ----------------------------8< cut here >8------------------------------ Without Curl: The diagnostics confuse as to what is actually going to be sent; if you know the code well enough to know where the messages come from, I'm confident it's clear, but myself? I had to use tcpdump to satisfy myself that the "Host:" line coming _before_ the "original" line was what actually got sent. But it looks as though the non-Curl case is now fixed for both bugs 1446 & 1447. Interesting that the HTTP request itself got split into two packets. ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = GnuPG curl-shim Host: keytest.spodhuis.org Command: GET * HTTP proxy is "null" * Original HTTP URL is "http://keytest.spodhuis.org:11371/pks/lookup?op=get&options=mr&search=0x403043153903637F"; * SRV tag is "pgpkey-http": URL may be overridden * HTTP auth is "null" * HTTP method is GET * HTTP host:port post-SRV is "keyserver.spodhuis.org:11374" ----------------------------8< cut here >8------------------------------ ----------------------------8< cut here >8------------------------------ 02:35:22.942405 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 136) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: P, cksum 0x131c (correct), 1:105(104) ack 1 win 32844 <nop,nop,timestamp 3873907875 991822204> 0x0000: 6009 380b 0088 0640 2a02 0898 0031 0000 `.8....@*....1.. 0x0010: 0048 4558 0073 6b73 2a02 0898 0031 0000 .HEX.sks*....1.. 0x0020: 0048 4558 0073 6b73 ffa4 2c6e e223 9b76 .HEX.sks..,n.#.v 0x0030: 1ab3 cf49 8018 804c 131c 0000 0101 080a ...I...L........ 0x0040: e6e7 24a3 3b1e 017c 4745 5420 2f70 6b73 ..$.;..|GET./pks 0x0050: 2f6c 6f6f 6b75 703f 6f70 3d67 6574 266f /lookup?op=get&o 0x0060: 7074 696f 6e73 3d6d 7226 7365 6172 6368 ptions=mr&search 0x0070: 3d30 7834 3033 3034 3331 3533 3930 3336 =0x4030431539036 0x0080: 3337 4620 4854 5450 2f31 2e30 0d0a 486f 37F.HTTP/1.0..Ho 0x0090: 7374 3a20 6b65 7974 6573 742e 7370 6f64 st:.keytest.spod 0x00a0: 6875 6973 2e6f 7267 3a31 3133 3731 0d0a huis.org:11371.. 02:35:22.942487 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 77) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: FP, cksum 0xe48f (correct), 105:150(45) ack 1 win 32844 <nop,nop,timestamp 3873907875 991822204> 0x0000: 6009 380b 004d 0640 2a02 0898 0031 0000 `.8..M.@*....1.. 0x0010: 0048 4558 0073 6b73 2a02 0898 0031 0000 .HEX.sks*....1.. 0x0020: 0048 4558 0073 6b73 ffa4 2c6e e223 9bde .HEX.sks..,n.#.. 0x0030: 1ab3 cf49 8019 804c e48f 0000 0101 080a ...I...L........ 0x0040: e6e7 24a3 3b1e 017c 4361 6368 652d 436f ..$.;..|Cache-Co 0x0050: 6e74 726f 6c3a 206e 6f2d 6361 6368 650d ntrol:.no-cache. 0x0060: 0a50 7261 676d 613a 206e 6f2d 6361 6368 .Pragma:.no-cach 0x0070: 650d 0a0d 0a e.... ----------------------------8< cut here >8------------------------------ Regards, -Phil _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
