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

Jason Harris <[email protected]> Sat, 27 Nov 2004 10:08:29 -0500
Newsgroups gmane.comp.encryption.gpg.user,gmane.comp.encryption.pgp.keyserver-folk
Message-ID <[email protected]>
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?
[email protected] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
signature.asc (application/pgp-signature, 187 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFBqJhsSypIl9OdoOMRAkSgAKCMwHdgM5X+5SZJsZ7MhTAebR9ZIQCeJbk4
odtKECWt3mkFQwfO/wQ9fKg=
=mVgH
-----END PGP SIGNATURE-----