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

[Yaron M. Minsky]

I'll cop to that.  I know little about the details of HTTP, and my
original implementation was horribly non-compliant (SHOULDs aside) until
others pointed out the errors.  It may still be broken.

Right now, I don't think query load is a big deal for most keyserver
operators.  As such, upgrading the HTTP behavior seems like a low
priority for me.  That being said, I'm always happy to accept patches
(or even careful and detailed suggestions as to implementation
strategy.  Patches are more likely to lead to changes, however.)

Yaron

On Fri, 2004-04-09 at 09:46, John Belmonte wrote:
> Hello,
> 
> While looking for keyserver software to tinker with, I stumbled upon 
> pkspxy, the key server proxy.  That got me wondering why keyservers 
> would need a custom proxy.  Well, looking at the HTTP response headers 
> of a key request explains a lot.  For example, here is the response to 
> <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4C40410A>:
> 
>      Server: pks_www/0.9.6
>      Content-Type: text/html
> 
> No doubt the keyserver designers were skilled in many areas, but I don't 
> think HTTP was one of them.  (Yes, SKS is in the same boat.)
> 
> 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.
> 
> In summary, I'd like to see keyservers follow the SHOULD's in the HTTP 
> RFC.  Bonus points for following REST principles.
> 
> -John Belmonte
-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916