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

[Andreas Hartmetz]

On Wednesday 28 April 2010 07:06:35 you wrote:
> 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.
Looks like I didn't read the RFC very thoroughly ;)
> 
> 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...

Thanks for the informative write-up.
I'd rather add a new KIO command code. That would be safer (credentials can 
never mix with other metadata) and cleaner.
When sending the HOST command the scheduler or some other central part of KIO 
could transmit the credentials just for that host. This may or may not get 
tricky with redirections (I haven't looked at any relevant code recently). 
Redirections have been the most productive source of hard to catch bugs in my 
KIO adventures...
In your patch I don't see mechanisms to send credentials to slaves created 
after the first slave has been asked for credentials, to update already running 
(not idle) slaves that haven't been asked for credentials yet, or any kind of 
credentials lifetime management. These are the hard parts.
So, using the hardest-part-first approach: how shall we manage the lifetime and 
propagation of credentials?
Adding a new command or not will be easy.

Cheers,
Andreas