Re: [Sks-devel] SKS, Content-Length and HEAD requests

[Phil Pennock]

On 2010-11-02 at 16:20 +0100, Marian Kechlibar wrote:
> The main principle would be to issue a HEAD request first, instead of
> a GET request. Then, the client would parse the reply header, and look
> for Content-Length HTTP header. According to the value therein, the
> user could be prompted again - like "Your search is too general - do
> you really wish to proceed? % MB of data will be downloaded", and,
> also, the estimated time of arrival could be calculated (based on
> properties of the currently connected network). And, if the user
> approves the GET request, a progress bar could be shown and updated
> according to the real download progress.
> 
> This would be very comfortable, but it would require support for HEAD
> requests and for Content-Length headers. I am not sure how much effort
> does this require, as I have never written code of a server-side
> software. I am also not sure whether such change wouldn't contradict
> philosophical principles of the SKS project.
> 
> Please let me know what you think.

Note that the best person to ask is David Shaw, since he wrote the
almost-standard for HKP.  I believe that he reads this list.  If he
contradicts anything I write below, go with his opinion.

You've just added an extra round trip for the cases where the request is
specific, which makes things slower.

The HKP protocol accepts various options and modifier variables.  Why
not a "limit" variable which takes a positive integer?
  * if there are at most $limit matches, return them
  * if the limit option is present, in all cases add an
    X-HKP-Results-Count: header, which says how many results were
    present

I don't believe that there's any guarantee of consistent ordering of
results, and new keys could arrive between subsequent requests, so
adding an "offset" variable to basically do windowing isn't going to be
entirely safe.  Especially if using DNS round-robin to find servers.

You might find that in practice, an offset variable works "well enough"
for the common cases, if clients are fairly robust.  Anything better
would be a new protocol which has authentication so that the server can
maintain state on behalf of clients and return a result-set id code.
You don't want to go there.

But one extra variable, which might be &limit=10 adds 9 characters to
the request, and 22 to 30ish characters to the response, adds no extra
round-trip latency for the cases of good matches, makes no change in
behaviour for clients not using the option ... seems to me like a better
approach.

There's no formal standard for HKP; there is
  http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00
and per that, it might be &x-limit=10 instead.

Regards,
-Phil

pgpi0y6Iqgeew.pgp
Description: PGP signature