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-----