[Sks-devel] 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-----