[pgp-keyserver-folk] poor use of HTTP in keyserver designs

Jason Harris jharris at widomaker.com
Sat Nov 27 16:08:29 CET 2004


On Wed, Nov 24, 2004 at 06:38:25PM -0500, Jason Harris wrote:
> On Sun, Nov 21, 2004 at 08:19:12PM -0500, Jason Harris wrote:
> > On Fri, Apr 09, 2004 at 09:46:19AM -0400, John Belmonte wrote:

> > > I'd like to see the HTTP response headers improved.  For example, use of 
> > > entity tags would allow clients and proxies to poll for key changes with 
> > > minimum burden to the server.  Combined with proper cache control 
> > > headers, general HTTP proxies could serve the keyserver network well.
> > 
> > Clients like wget only use timestamps, which I assume most browsers
> > limit themselves too as well.  Do you know which browsers use ETag
> > for cache control?  But, note that neither pks nor SKS currently index
> > key IDs/fingerprints/hashes to their last update times.
> 
> keyserver.kjsl.com is now generating Date:, Content-Length:, and
> Content-MD5: headers for most replies.  Additionally, it now supports
> HEAD requests with these headers included.  Note that the PHP4 page(s)
> that support port 80 access do not generate the latter two headers,
> however.

The PHP4 page is now generating its own Content-Length: and Content-MD5:
headers, as well as reusing the Content-MD5: hash for the ETag: header.
(http://www.aota.net/ubb/Forum15/HTML/000749-1.html shows how to
generate such ETags in PHP.)  wget can generate a request to show that
ETag-only comparisons work (in this Apache-served page that doesn't
also generate a Last-Modified: header):

  wget -s -S --header='If-None-Match: e54d91e9622bdeb2d3f871235108c97b' \
  'http://keyserver.kjsl.com:80/pks/lookup?op=index&search=0xd39da0e3'

(NB:  As always, please access the keyserver directly on port 11371
whenever possible.)

> proxies/clients.  However, clients like GPG might start checking the
> MD5 hashes of received keys and/or issuing HEAD requests to see if
> the hashes have changed since the keys were last downloaded from a

Developers, feel free to exercise this page to test/verify new ETag-
only cache-control semantics in HTTP/HKP clients until keyservers
support them directly.  Note that the page also supports HEAD requests,
so you can build actual ETag: lists without downloading keys that may
only be interesting when they change.

-- 
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/20041127/33799a70/attachment-0001.bin


More information about the Gnupg-users mailing list