WinPT key POSTing problem

[Jason Harris]

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


  (cmd path                                    User-Agent:  Host:)
  POST http://wwwkeys.us.pgp.net:11371/pks/add "WinPT/W32" "wwwkeys.us.pgp.net:11371"

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" "http://subkeys.pgp.net:11371"

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]
keyserver.kjsl.com 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 widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          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