WinPT key POSTing problem

Jason Harris jharris at
Sun Dec 19 22:09:48 CET 2004

A few WinPT users popped up in my keyserver log recently.  Some were
sending a bad POST command:

  (cmd path                                    User-Agent:  Host:)
  POST "WinPT/W32" ""

It is an error to have http+hostname+port in the POST path, only the
local path, /pks/add, is correct.  These were given an HTTP 404 response.
In this instance, the Host: header is correct, and is the proper place
to include the hostname and port number.

Of course, another user sent a malformed Host: header:

  (cmd path     User-Agent:  Host:)
  POST /pks/add "WinPT/W32" ""

but was at least able to post their key.  (There are no checks on the
value/validity of the Host: header at this time.)  However, the "http://"
is incorrect and needs to be dropped from Host:.

I also notice these requests were identified as HTTP/1.0.  Other than
understanding and sending "Connection: close" headers, is there a reason
to not identify them as HTTP/1.1 requests?

[new feature] has been generating (HTTP/1.1) ETag: headers, first
on port 80 (a PHP page), followed shortly by port 11371 (patched pks).
It also supports HEAD requests and ETag: cache-control semantics, albeit
only for single ETags (in the If-None-Match: header).  If WinPT were to
store the ETag: as it downloaded each key, it could ask for that key and
send 'If-None-Match: "<last ETag:>"\r\n' in order to get the key only if
it has changed.

Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at _|_ web:
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20041219/1a8cfa5f/attachment.bin

More information about the Gnupg-users mailing list