Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop

[David Shaw]

On Mar 3, 2013, at 3:54 PM, "Bernd Eckenfels" <lists-gnupgdev at lina.inka.de> wrote:

> Am 03.03.2013, 02:38 Uhr, schrieb David Shaw <dshaw at jabberwocky.com>:
>> Ok, this is reasonable.  I'll add some code to gpgkeys to look for the HTTP status.  It'll only really work properly on sks 1.1.4 or later, but it'll work well enough on earlier versions (it'll say "key can't be retrieved" rather than "key not found" if the key isn't found).  That addresses all 4 cases here, since gpgkeys can use those status codes, along with the state it already has, to tell the difference between key found (either complete or incomplete), not found, and server failed.
> 
> For an aorted transfer, it is required to check for Content-Length or
> Chunk borders. I dont see how the status code would/could help. Since an
> aborted transfer still has a status of 200.

Unfortunately, some SKSes out there do not provide Content-Length.  That doesn't matter, as gpgkeys knows something about the object being fetched (i.e. it's a key).  It currently tells the difference between the various cases as such:

HTTP 200: if key has both BEGIN and END, success.  If key has only BEGIN, incomplete.  If key has neither BEGIN nor END, fail.
HTTP 404: key not found.
HTTP (anything else): fail.

David