No query attachments allowed for urls passed to kioslaves?

[Friedrich W. H. Kossebau]

Hi David,

Le mardi, 10. février 2009, à 13:17, David Faure a écrit:
> On Sunday 08 February 2009, Friedrich W. H. Kossebau wrote:
> > Le dimanche, 8. février 2009, à 15:04, Friedrich W. H. Kossebau a écrit:
> > > Le dimanche, 8. février 2009, à 11:35, Allan Sandfeld Jensen a écrit:
> > > > > If yes,
> > > > > is there a reason querys get stripped from urls before they get
> > > > > passed to a kioslave?
> > > >
> > > > No, querys to not get stripped from urls, otherwise most PHP/ASP
> > > > sites would not work at all. So you have probably encountered some
> > > > special bug.
>
> Let's not confuse HTTP get and listing with KDirModel :-)
> I assume that your service kioslave shows directories and is therefore
> going via KDirModel when being displayed in a dolphin view (in dolphin or
> konqueror).

Yes, correct. Listing directories of service types and subdirectories of 
matching service items.

> In KDirModel there is code to strip out queries, the code says: 
>
> * For instance ksvn+http://url?rev=100 is the parent for
> ksvn+http://url/file?rev=100 * so we have to remove the query in both to be
> able to compare the URLs

For the comparison perhaps, but later on?

(Oh, ksvn+http? Good to learn about that. As from here*?
* http://kdesvn.alwins-world.de/browser/trunk/src/kiosvn )

> but actually I'm not sure this is still needed now that there's a global
> hash of nodes, and also the idea was not for such stripped urls to go back
> to kioslaves (although maybe it happens when expanding nodes in a
> treeview).

So this behaviour also breaks ksvn+http, and should be fixed, or?

> But I would need more details and you changed your kioslave 
> already, so I guess we should move on for now?

Perhaps not yet, please. I am working on the SLP* kioslave, which lists 
services on the net. The only unique identifier of a service is the url of 
that service, so I need to use it in the service:/ url, to be able to map it 
back to the service from a KUrl used in a request to the kioslave, e.g. to do 
a redirect.
The old code used the host part of a url to store the service type 
description, and put the host and the path (the site) of the service into the 
path part of the service:/ url (still with me? :)

kioslave url    service url
service:/
host         <- type,  e.g. printer:lpr
path         <- site (host+path), e.g. /intern.company.com/queue

I felt this was not perfect:
* Will the host syntax match all possible service type descriptions?
* Does not match the approach of the zeroconf kioslave.
* Where to encode different domains to look for services?

My first idea was to put the complete service url into the encoded query part, 
to circumvent any syntax problems. Which breaks the needs of KDirModel, with 
a hierarchical naming structure, is this still valid?

So approch #1 seems flawed.

* http://websvn.kde.org/trunk/playground/network/kio_slp/
http://en.wikipedia.org/wiki/Service_Location_Protocol

> > > Meanwhile I encoded the service url in the path. The url
> > > 	service://workstation/fantasy/gibt.es.auch.nicht/
> > > works if I click on it, but if I enter it in the url bar and press
> > > enter, the kioslave receives the url with the trailing "/" cut away
> > > 	service://workstation/fantasy/gibt.es.auch.nicht
>
> Well, that shouldn't matter, should it? if foo is a directory then foo and
> foo/ are about the same thing, when listing them with kio (this is about
> listDir, right?)

More "stat", as this is triggered if entering into the url bar and pressing 
enter, also on reload.

The next idea, as implemented now, was to turn back to the old version and map 
the complete service site into the path, the type into the host (Just that 
this breaks if asking to the KDirModel to move one level up, because the 
slashes do not match the real hierarchy).

And the problem as mentioned above is that the 
service "service:ftp://myhost.kde/" would be expressed 
as "service://ftp/myhost.kde/". But if the trailing slash is removed this 
expression is broken. Especially as there could be 
also "service:ftp://myhost.kde/some/path", expressed 
as "service://ftp/myhost.kde/some/path".

Can be solved by some extra code in the kioslave, because the path level where 
this can happen is known, I was just surprised about the behaviour, because I 
set the complete urls explicitely with UDS_TARGET_URL.

But this approach is also flawn, given that the KDirModel operates on the 
slashes as level separator.

Perhaps one should use hash values for the mapping? 

Or what would you propose here for the construction of the service:/ url?

> > > Looking at the log (attached) I wonder:
> > > How comes
> > > 	KParts::BrowserRun::scanFile: MIME TYPE is "inode/directory"
> > > when none of the slots in my kioslave are called to find this out?
> >
> > Because currently it uses KMimeType::findByUrl( KRun::url() ) for all
> > non-http and queryless urls. And ends with guessing from the listing
> > capability and the trailing "/" it will be a directory.
> > 00375             if ( prot && prot->supportsListing() ) {
> > 00376                 KMimeType::Ptr mime = mimeType(
> > QLatin1String("inode/directory") );
>
> Right. Is this a problem? Why do you have a trailing "/" in the first place
> if it's not a directory?

service://ssh/192.168.0.2/

> But you can disable this if you add
> defaultMimetype=application/octet-stream to your .protocol file like
> kio_http does. It basically means: don't assume anything from just looking
> at the URL.

Oh, good idea. Will test.

> > But why did I then reimplement the mimetype( KURL ) method of
> > KIO::SlaveBase?
>
> That's for the KIO::mimeType() job, which is asynchronous (and therefore
> not used by fast KMimeType::findByUrl).

Where then?

> > Could there perhaps be a flag that there the protocol has lightweight
> > mimetype detection?
>
> I think the above flag will do.

If it works, shall I add this to the Api dox?

> > This could also help with the rest of BrowserRun::scanFile(),
>
> Yes, it will now call get(), from which you're supposed to emit the
> mimetype. Well, for files! If this is supposed to be a directory (I'm
> confused about what you want exactly) then the call to KIO::stat() happens
> first and can tell it's a directory.

Before I looked at the definiion of the url syntax and did not find a clear 
paragraph which declares the slash to be a hierarchy separator, other than 
being used for that just usually. So I was under the assumption that the kio 
system is also prepared for unusual urls.
Well, with the hack using "defaultMimetype=application/octet-stream" it 
perhaps is ;) Hm, given the lack of non-usual urls so far it seems I need to 
adopt to the current KIO implementation, then :)

> > where I wonder why not just HTTPProtocol::mimetype( KUrl ) is used?
>
> Because this would involve two roundtrips to the HTTP server.
> Let's assume HTTPProtocol::mimetype is involved with HTTP HEAD (but
> that's so unreliable I'm not even sure that's still the case). If KRun
> called it then you would get, for any url typed in konqueror, a
> HTTP HEAD followed by a HTTP GET.
> Instead, what happens currently is that KRun starts a HTTP GET,
> which emits the mimetype before any data, KRun puts it on hold,
> tells konq to load the part for mimetype xyz, which then does a KIO::get
> which (via some magic in KIO scheduler) reuses the same kioslave
> and resumes the same HTTP get download.

Ah, so this is why mimetype() should be called as early as possible in get(), 
thanks. And this is the place of that famous solution, alright.

I have still some problems with this solution, but that might be descibed in 
another email, where I am going to propose a handling of service types using 
new mimetypes instead of kioslave protocol starters. But this needs some more 
prototype code to help you to understand my motivation.

> > > Still in the end it says
> > > 	konqueror(23113) KonqView::openUrl: url=
> > > KUrl("service://workstation/fantasy/gibt.es.auch.nicht/")
> > > locationBarURL= "service://workstation/fantasy/gibt.es.auch.nicht/"
> > > 	kio_slp(23115) ServicesSlave::listDir: url=
> > > KUrl("service://workstation/fantasy/gibt.es.auch.nicht")
> > > So who could munge away the trailing "/" between the two log enties
> > > (the url stays unchanged in ServicesSlave::listDir(), so it should not
> > > be the ioslave)
>
> KDirLister simplifies urls by removing the trailing slash, to make it
> easier to compare urls later on, but really, an ioslave isn't supposed to
> make a difference based on a trailing slash being present or not....
> Did you intend for those to be a different thing? That's very unlike
> normal directories.... I suggest to find another solution... (/index.html?
> ;)

:) Hope the above already answered this.

> > > I played with different values for "URIMode" in the protocol file but
> > > that had no effect
>
> Can't see a relation.

Nor did I (and I still haven't completly understood that parameter) but I 
tried anything I could before asking to see if it points me to a solution ;)

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta