SKS, Content-Length and HEAD requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

SKS, Content-Length and HEAD requests

Marian Kechlibar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Dear developers of SKS,

let me introduce myself: I work for a company which develops crypto
solutions for Symbian OS smartphones. I am a cryptographer by
qualification, nevertheless
I often do solve various non-cryptographical practical issues in the
Symbian code.

We have a utility which is able to communicate to PGP keyservers using
HTTP and HKP. SKS is a good software for this purpose. Nevertheless,
we ran into a small design deficiency which
demonstrates itself only in specific constrained conditions of mobile
networks.

Let us imagine the following situation:

- - the user selects a search phrase which returns too many entries
(say, a name that is too common),
- - SKS will start returning quite a huge stream of data (hundreds of
kilobytes and more).

On a normal PC with normal connectivity, this is not a huge problem.
Most of the queries are completed in a few seconds, unless the network
bandwidth is really low. Which is not so common nowadays.

Nevertheless, if the user is connected over a mobile network, he/she
can effectively kill the connection for quite some time. On 3G
networks, for, say, half a minute; on older 2G networks, which are
unfortunately still too common in Europe, for minutes.
Moreover, the user is often either charged money for the data
transfer, or, at least, subject to a Fair-Use Policy which is rather
low on mobile networks (100-500 MB per month). So there is non-zero
cost associated with issuing HKP GET requests over mobile networks.

If the user is, moreover, using a smartphone device, the processor
load associated with the huge arriving data load reduces responsivity
of the device noticeably.

There is a straightforward solution that avoids these problems for
mobile-connected clients, but it requires some modifications in SKS. I
am not sure whether these can be done realistically.

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.

Best regards

Marian Kechlibar


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM0Cw0AAoJEOJiGpwt9DuCITEP/i3o19pLMyYvGh1iRuoiaeoo
SVctbyHJ/pCosxc2+3CgXTR/li7UIMrmxD54WLOWyiPedDNJeMu0BPcxKmhvSB8o
aRSalNwUh1x73ZESkLkKCZGslFi6WvinQ5yYQt+H+O76ttWYV2M9+ONRDl1U3/v4
dzCNuE04aOEAZ9pVRW9zaNTqsZ3Po4Z5eusufFUtCRcnbODIu2OlugPmjGImUcVQ
JZteCCwB9zguy7rm162nCp1vDF/XPVaOtTllcMyZRStnaHoMYStq2DjOL2p7jwpy
7nmpsuG8wZIhOIBla5SGdjZquCfDXoHKPU4EOc6RSx4MBN57CNcx9BzyQ1tjH0Aj
NtyyQ8ZcoJgeZt6IHt7m6f1SL4p3zExABlf2012D6eLxwGFKrGqIuCKURkW3hwdP
PyJn0KO2rc956aHasvGEn2AB9lCDC2PTiiDCxVYDS+eS427oE549FR6kcop9vg8r
AoTWZbS1DY8gSL/ygrj8agfpE1YHzoX0mfZNucp0gMx821KACwUTAiwTOJpBjL5+
Bf2gmx98+9LvV6dY1PoFqJd2PzgVeNn4FxMA4E02Bm+H9ztxP3agYdvU/gJ7YSht
B3XYlyvewcyzePK//1e4us5MUhlfXMt0WdJDpwRPXunoguPH0xSpwHpVdBt+TLVw
EDv11CdKSMa6Wyzfp6XP
=P5Ke
-----END PGP SIGNATURE-----



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Phil Pennock-17
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

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Jonathan Oxer-4
On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
> 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.

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

My reading of Marian's suggestion was that it would be optional, not
required, so clients that are operating in constrained conditions could
choose to do the HEAD request followed (depending on the result) by a
GET request. Other clients could operate as normal by issuing a GET
request initially.

Phil's suggestion of a limit variable seems good, but there's also a
third option that may be worth considering: a command specifically to
retrieve metadata about a query result without retrieving the result
itself. There could be a command issued as a GET request in the same
format as a regular search, but rather than returning the result it
would return things like the number of results and the content length of
the full result set in a machine-parsable format. Or it could just be an
argument appended to the regular search.

--
Jonathan Oxer
Ph +61 4 3851 6600
Internet Vision Technologies: www.ivt.com.au

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Marian Kechlibar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hello all,

yes, in my suggestion, the HEAD method was optional, and only used by
constrained clients.

Jonathan's suggestion with metadata command would be as good.

Best regards

Marian

Dne 2.11.2010 22:45, Jonathan Oxer napsal(a):

> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>> 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.
>
>> You've just added an extra round trip for the cases where the
>> request is specific, which makes things slower.
>
> My reading of Marian's suggestion was that it would be optional,
> not required, so clients that are operating in constrained
> conditions could choose to do the HEAD request followed (depending
> on the result) by a GET request. Other clients could operate as
> normal by issuing a GET request initially.
>
> Phil's suggestion of a limit variable seems good, but there's also
> a third option that may be worth considering: a command
> specifically to retrieve metadata about a query result without
> retrieving the result itself. There could be a command issued as a
> GET request in the same format as a regular search, but rather than
> returning the result it would return things like the number of
> results and the content length of the full result set in a
> machine-parsable format. Or it could just be an argument appended
> to the regular search.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM0IeWAAoJEOJiGpwt9DuC7w4P/iohh8yozuKvoccxcZ/+VVjk
0CWnig+Y+C7VyTcR+9igU0sgKxrTrvei3TdNWRoF9fBcXGXKI2s8hR4VVhREmC5K
HqndF299rJkJ0vLXvsV32b6lJli+MEJGVjsIXtAYn10FTYPYK5eon2Qne+v8ZL0F
NamYKZQKgplv4cGSQoPoXScYw5WjrALveIS56G9fxEeMWhSf7PQTQP/eU3SgC7yA
br7k19rHBvgiSwZ7bqvL7dtvo9ZD7IH6NQXqrA4fUh8T5sVc7zeYggwO0Bz5SF1g
LAMm3XbrP8Bv73ie+rdhlagh44qIS9xbI6+wgLJobO8l2OSaYSAs1jtjfbRreDb3
OZ379SRMCf/3zvA47z8DPPJjC5rQSpNpyBMuj14gXcl9REhSx7Ypj6JGcdrv3gND
8P0oY9Dy1YNwsGMFYK2fj3hicHZfZIX+Jwlkqiv+SxkKjvSTHLWPuYPjPpqzZYKv
PhON9cOgTS9SQ1Fag87R+wfwuK9frErU7cxFkMO3ClWyuIjHFkwyPJrUiRiGGKtw
WXCTH6Knnmw9/VpnNCi+hgLDry/neooR3gZHL6V+wnpkLv/u7/g00FpS+C4JT5mO
W6POIHLA2PZMT9L7t6t9wpt2kVlwvXGnURWxknoySYi8P8S4hXi3Uw8c9ZrvKrGZ
ks196KK4YgPc5XbrL3YP
=9jEs
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

John Clizbe-3
In reply to this post by Jonathan Oxer-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jonathan Oxer wrote:

> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>
> Phil's suggestion of a limit variable seems good, but there's also a
> third option that may be worth considering: a command specifically to
> retrieve metadata about a query result without retrieving the result
> itself. There could be a command issued as a GET request in the same
> format as a regular search, but rather than returning the result it
> would return things like the number of results and the content length of
> the full result set in a machine-parsable format. Or it could just be an
> argument appended to the regular search.

I believe that's already implemented

http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=index

and

http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=vindex

- -John

- --
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:[hidden email]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12-svn5475-2010-10-29 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the £€37 ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkzQxBIACgkQ614Z89ZWmCV5aAD8C4v03iSyQs2s2PpfZi3dYDbn
jcrMKCfLRKsITKqIrlkA/A7PQzZPrYJK48OVx8Ho3o9s6ijM3zydf8g3wAFy+ivK
=yDTM
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

John Clizbe-3
John Clizbe wrote:

> Jonathan Oxer wrote:
>> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>
>> Phil's suggestion of a limit variable seems good, but there's also a
>> third option that may be worth considering: a command specifically to
>> retrieve metadata about a query result without retrieving the result
>> itself. There could be a command issued as a GET request in the same
>> format as a regular search, but rather than returning the result it
>> would return things like the number of results and the content length of
>> the full result set in a machine-parsable format. Or it could just be an
>> argument appended to the regular search.
>
> I believe that's already implemented
>
> http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=index
>
> and
>
> http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=vindex
>
> -John


Oooops add &options=mr to each of those

s/implemented/mostly implemented/


--
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:[hidden email]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Marian Kechlibar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Dear John,

what is the difference between index and vindex? I ran both queries
and couldn't find any visible differences.

Best regards

Marian

Dne 3.11.2010 3:48, John Clizbe napsal(a):

> John Clizbe wrote:
>> Jonathan Oxer wrote:
>>> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>>
>>> Phil's suggestion of a limit variable seems good, but there's
>>> also a third option that may be worth considering: a command
>>> specifically to retrieve metadata about a query result without
>>> retrieving the result itself. There could be a command issued
>>> as a GET request in the same format as a regular search, but
>>> rather than returning the result it would return things like
>>> the number of results and the content length of the full result
>>> set in a machine-parsable format. Or it could just be an
>>> argument appended to the regular search.
>>
>> I believe that's already implemented
>>
>>
http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=index
>>
>>
>>
and
>>
>>
http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=vindex
>>
>>
>>
- -John
>
>
> Oooops add &options=mr to each of those
>
> s/implemented/mostly implemented/
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM0QJPAAoJEOJiGpwt9DuC0o4P/RN7TP1W9Nmh7/S0a1+jClf6
W5yW1XaFItIBU8pcrROAAsoYvwBwH9RULNH42A/oqsFd8cd/r5R1eR1uXykV1ICe
MWeI5Vn02LgGs1+TFjQk1i9wwb7BmdJxwQ6fJNB+4uK/zS3AQl+lPOTz9HbMnMoq
1QN/cACUZl55a/2in8zMIlRNw0RxZCfjRUQL8rfuHZvVUKsG3hd7jPCexyvsBYRs
mjrsNBTfqsBNGMJmlnzmz8QRPUcGM6HCg7TrbbgZAaVakhBpUH9X5qYZtPB/IpdA
hqtR1tFr257CZ3JMdc3rcdauiePH1/WpAkJ6OMhjmdtLMv/SanLAydh4Ito/uPYS
BoPvIxbrry0R1/kcD72YHf1RyOZZuNm3FrbOfSJNKs83o1vmeKkbYg+TMCf7tUuQ
LnHMA5CZc06m+CpRrJViO4LAk2nx3IX1d+R2ncqV9kWNJc9urGWGC2QHpNBJCcj3
/eGr5YCSbqMR4dtr4TfhcKYza6jmqIQ3eOVB/aep65+N2Wo2zhpBZdfKAdSX83Bx
idXUMx2QDojZtzQbXqAlIupbIyiqi/fJp5pvQvf9vrfosd4W/McLpstuxVzGCNjE
LYW4w4wL1Gv1piZOEaCiF3zO8D4bSeIkVDNIryk0oaGLgXMGJZ6IOb/Cvbm8Iaus
zXFizRw3UAPs6qhUh5vZ
=zCIA
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Marian Kechlibar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Retracting my earlier query ... I found the explanation in the draft.
Nevertheless, if I run larger queries (say: search "Novak", which is a
common Czech name),
I find a strange field uat:::: scattered across the machine-readable
output. This field
is not described in the draft.
Can anyone comment on the meaning of uat::::? The only thing that
google found was User Acceptance Testing, which sounds implausible.

Best regards

Marian

Dne 3.11.2010 7:33, Marian Kechlibar napsal(a):
>
> Dear John,
>
> what is the difference between index and vindex? I ran both
> queries and couldn't find any visible differences.
>
> Best regards
>
> Marian
>
> Dne 3.11.2010 3:48, John Clizbe napsal(a):
>> John Clizbe wrote:
>>> Jonathan Oxer wrote:
>>>> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>>>
>>>> Phil's suggestion of a limit variable seems good, but
>>>> there's also a third option that may be worth considering: a
>>>> command specifically to retrieve metadata about a query
>>>> result without retrieving the result itself. There could be a
>>>> command issued as a GET request in the same format as a
>>>> regular search, but rather than returning the result it would
>>>> return things like the number of results and the content
>>>> length of the full result set in a machine-parsable format.
>>>> Or it could just be an argument appended to the regular
>>>> search.
>>>
>>> I believe that's already implemented
>>>
>>>
> http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=index
>
>
>>
>>>
>>>
> and
>>>
>>>
> http://keyserver.gingerbear.net:11371/pks/lookup?search=clizbe&fingerprint=on&op=vindex
>
>
>>
>>>
>>>
> -John
>
>
>> Oooops add &options=mr to each of those
>
>> s/implemented/mostly implemented/
>
>
>


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM0QfCAAoJEOJiGpwt9DuCDqsP/2zn+8XRCvbDjng3vByoW1up
VA+WY9ISsOSMl/U5b6ADc914dSgukfnpmbs6TkWChDhPFizoQkvZnpHXb1UHhhio
6LF4ue3Ra+g+WC2DmKDpaX96L7FL0xZdOJJ8yITvC0b2eSGq8nJEpmKswWfLeEYx
EolS/gSzrOZNMjuJK13vz0y4Ig1rpJJNcdbmja7anQ1IHMRyNZt2Gtidq/vNGZ2D
18nKCKUwdNFmylJ7LIHsq/YtYk9yBsBGjffe1Ktahcx1C6yCdlBMG0IuocbkogvN
QVNqD4rA7PGxt3Taz/y9fOLc2AtVlOVdRUPymUYRKxTadK84XgfXKwdgS6eTL3OB
y7QYMlCU0YQhvIRLy4+sQyaWYlyH83Hjo9gbOacXf66CztLfmMuEyZra/XUozXEI
Vn2aqvVQYuZ53K4aDeaqcDufzJQfonTreI7X/oALfPgoKCkNgY1eNF1XUU1tZJ5V
ZVVFq2z/I16WyCK49m1juohn/2kT3wZLmHWcdHV362TfJInO3vlG7yKBN1RdEibD
yj/iSM4q0lJQoxuUzhgp6HNjllFsZ2D0Wbv4Np1GZsuz2L+3K8Is+Wd7ZKmhmu5R
5Z/L6WtVXAHyFrvvIQK5i7lTl7bc1TzelmvF1NvDu7CKGJLiOLm+bQmDyKZhV3eq
cHxbtdX8PAf7gQm0MAtw
=uMfY
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Phil Pennock-17
On 2010-11-03 at 07:57 +0100, Marian Kechlibar wrote:
> Nevertheless, if I run larger queries (say: search "Novak", which is a
> common Czech name),
> I find a strange field uat:::: scattered across the machine-readable
> output. This field
> is not described in the draft.
> Can anyone comment on the meaning of uat::::? The only thing that
> google found was User Acceptance Testing, which sounds implausible.

User Attribute Packet (User ATtribute).

There are currently never any fields filled in, ie it's always shown as
"uat::::".  Content tag 17.

RFC 4880 section 5.12.

RFC notes it's used for holding images (only defined subpacket type).

-Phil

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

David Shaw
In reply to this post by Jonathan Oxer-4
On Nov 2, 2010, at 5:45 PM, Jonathan Oxer wrote:

> On Tue, 2010-11-02 at 13:20 -0400, Phil Pennock wrote:
>> 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.
>
>> You've just added an extra round trip for the cases where the request is
>> specific, which makes things slower.
>
> My reading of Marian's suggestion was that it would be optional, not
> required, so clients that are operating in constrained conditions could
> choose to do the HEAD request followed (depending on the result) by a
> GET request. Other clients could operate as normal by issuing a GET
> request initially.
>
> Phil's suggestion of a limit variable seems good, but there's also a
> third option that may be worth considering: a command specifically to
> retrieve metadata about a query result without retrieving the result
> itself. There could be a command issued as a GET request in the same
> format as a regular search, but rather than returning the result it
> would return things like the number of results and the content length of
> the full result set in a machine-parsable format. Or it could just be an
> argument appended to the regular search.

I like this idea.  I think you could implement this in terms of Phil's limit idea, too: just request a limit of 0.  Since Phil's design always responds with a X-header containing how many hits there were (regardless of how many were actually returned), then you get the information you were looking for.

David


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

Johan van Selst
In reply to this post by Phil Pennock-17
Phil Pennock wrote:
> 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

Sounds good. I have written a proof-of-concept patch that does this
(now running at keyserver.stack.nl). Note that I'm no sks committer and
not even an OCaml programmer. Maybe somebody who knows his way around
the source better than I could review this and decide if it makes sense
to add this to sks.


Regards,
Johan

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

sks-limit.patch (6K) Download Attachment
attachment1 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SKS, Content-Length and HEAD requests

John Clizbe-3
Johan van Selst wrote:

> Phil Pennock wrote:
>> 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
>
> Sounds good. I have written a proof-of-concept patch that does this
> (now running at keyserver.stack.nl). Note that I'm no sks committer and
> not even an OCaml programmer. Maybe somebody who knows his way around
> the source better than I could review this and decide if it makes sense
> to add this to sks.

Also running on my server, keyserver.gingerbear.net

Committed to my mercurial repo as changeset 45:68f88ae59b6a
https://code.google.com/r/johnclizbe-sks-keyserver

-John
--
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:[hidden email]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel