gnupg --fetch-key problems

[Björn Jacke]

Hello Werner,

On 01.09.20 10:10, Werner Koch via Gnupg-users wrote:
>> HTTP/1.1 would require support for things that currently may not be
>> present, such as chunked transfer encodings, whereas HTTP/1.0 is
> 
> That is for the server site but not for the client.  IIRC, the only
> mandatory request header for a client has is "Host:".  This is optional
> in 1.0 but we have always send this.  I see no benefit for requiring 1.1
> and also no reason why a site should block 1.0 - that would be a pretty
> lame DoS mitigation because bots could also send 1.1 without any
> problems but don't do so because it is not needed.

you may find it lame or not, disabling http 1.0 is recommended at a
number of places and a number servers out there already have it disabled
and it will probably be more and not less sites doing that in the
future, that's nothing that we can change. Ignoring all those sites and
let the gpg users suffer by not being able to connect would not be nice.

I talked with Wiktor about the http 1.0 issue in gpg and he also
mentioned that a number of weird problems that people have reported with
WKD in the past might be related to gpg talking http 1.0 only.

You didn't mention the suggested libcurl yet - if you would use that you
would not have to worry about the details of how to implement more
modern http protocols in gpg.


>> I agree it should provide an User-Agent, though.
> 
> There is no User-Agent header to minimize the amount of identifiable
> information.  You want a User-Agent header to make debugging requests
> easier?

yes, I found out that the trouble making http clients are gpg clients
only because Wiktor found that out by chance.

Best regards
Björn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200901/b5f23078/attachment.sig>