[PATCH] Request for adding internal meta-data support to KIO...

[Dawit A]

Purpose:
======
Allow io-slaves to send meta-data to one another that is not accessible from
the application level.

Reason:
=====
This patch actually grew from a need to fix authentication caching issues in 
kio_http. Let me explain a little about the problem to make it crystal clear 
why such a solution is essential. kio_http like every other ioslave uses 
kpasswdserver to store and retrieve authentication information which currently 
is accessed over dbus from KIO. Nothing wrong with that except kio_http needs 
to query this service each and every time it processes a request. It needs to 
do this because it wants to preemptively send authentication header and avoid 
round-trips to sites the user had already already authenticated to. However, 
doing so would have meant sending gazillion requests over dbus. 

That brings us to the problem... When kio_http was rewritten/updated for KDE 
4.x, the idea of preemptively sending authentication header was put aside to 
avoid the unnecessary abuse of the dbus resource. Instead, kio_http was 
changed to always wait for a 401/407 response from the server before 
attempting to send any authentication header. Unfortunately, that breaks 
things in in more ways than one. Not only does opting to wait for a response 
from the server causes three or more round trips to access every resource from 
a protected website now, but it also breaks sites that rely, correctly I might 
add (see RFC 2617), on the fact that once authenticated, the client will cache 
and preemptively send back the authentication header whenever appropriate. In 
other words, they do not expect yet another authentication again. See bug# 
181833 or the others marked duplicate of it. 

Solution:
======
The obvious solution to the problem described above is to have the first 
ioslave that successfully authenticates against a protected website somehow 
communicate this fact to all other io-slaves that are going to access a 
resource from this site. That way only those io-slaves would know they need to 
check for cached authentication information and send it preemptively, hence 
solving both of the problems for us...

What was surprising here is that the above solution can be implemented very 
easily. With only one additional requirement to qualify meta-data as internal, 
we can use the existing method that ioslaves use to send meta-data back to 
applications to solve the issue. What is this requirement ? We simply 
state/assume that a meta-data whose key starts with the keyword 
"_kio_internal_" will be treated as an internal meta-data and handled 
separately from the regular meta-data container that holds values slated to be 
sent to applications. You can read the details of how this is supposed to work 
by either reading the attached patch or simply reading the changes I made to 
the DESIGN.metadata document which is included with the patch.

Comments, objections, suggestions are all welcome...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kio_internal_metadata.patch
Type: text/x-patch
Size: 5973 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100428/28ab213b/attachment.bin>