--===============6518237823627874725==
Content-Type: multipart/signed; boundary="nextPart2219081.kFBWcbsFsg"; micalg="pgp-sha256"; protocol="application/pgp-signature"


--nextPart2219081.kFBWcbsFsg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Tuesday 04 November 2014 21:47:36 you wrote:
> On Sunday 02 November 2014 13:43:50 =C0lex Fiestas wrote:
> > Hi there
> >=20
> > There are quite a few places where the following code is found:
> >=20
> > if (!url.path().endsWith('/')) {
> >=20
> >     url.setPath(url.path() + '/');
> >=20
> > }
>=20
> Right.
>=20
> > Given an url like: 'scheme://' KUrl will return '/' as path
>=20
> Wrong.
>=20
> http://www.davidfaure.fr/2014/kurltest.cpp.diff
>=20
> KUrl remote2("remote://");
> remote2.path() is empty, not "/".
>=20
> > while QUrl returns empty string.
>=20
> Just like KUrl, yes. There is no path in scheme://.
>=20
> Reminder, it's scheme://optional_hostname/path (where path actually i=
ncludes
> the leading slash).
>=20
> > This is making kio add a third slash to the url in many places (bec=
ause of
> > code like the one pasted before).
>=20
> Right. Indeed, the above code turns "no path" into path=3D=3D'/', whi=
ch is wrong
> they mean different things. The canonical example is ftp://host (on a=
 non-
> anonymous ftp server) which usually redirects to ftp://host/home/user=

> > As a result if you open dolphin and type smb://, it will be redirec=
ted to
> > smb:///.
>=20
> I forgot the details of smb urls. I know it's tricky though ;)
> And yeah, a path of '/' sounds wrong.
>=20
> > Is this an intended behavior or should I start sending patches to p=
revent
> > this from happening?
>=20
> Well, this shows that we might need something in QUrl. The repetition=
 of the
> above 3 lines is already bad enough, anything more complex will surel=
y be
> wrong in many cases...
>=20
> KUrl had AppendTrailingSlash, QUrl is missing that (e.g. in adjusted(=
)).
>=20
> But wait. We can only append to the path after we already connected
> (to give a chance to ftp://host to redirect to ftp://host/home/user).=

> If we start doing any sort of path concatenation at that point, we'll=
 mess
> up. Imagine the complete code was changed to
>  if (!url.path().isEmpty() && !url.path().endsWith('/')) {
>      url.setPath(url.path() + '/');
>  }
>  and that this is followed by
> url.setPath(url.path() + "file");
> then we'll end up with smb://file.
>=20
> So I guess this is only happening in cases where we want to normalize=
 all
> paths (to end with a slash) before we even call listDir ... so that w=
ould be
> in KDirLister::openUrl? With a bit of luck this is basically the only=
 place
> where this logic would be needed? Well, all of KDirLister, since the =
whole
> point is to be able to rely on the fact that the url to a directory e=
nds
> with a '/', in there. If this is true, then I would suggest a helper
> function in kdirlister.cpp. If more code needs this, please explain, =
and it
> will be a reason for putting it in QUrl.

I have been taking a look at this today and I have to confess that I am=
=20
clueless.

kdirlister does not have any logic regarding paths right now.
KCoreDirLister (which kdirlister inhertis from) does but it is not addi=
ng any=20
slash as far as I could see and on all places at least within openUrl t=
he url=20
is not modified (aka no extra slash is added).

Also, if you run "dolphin smb://" a weird thing will happen, the widget=
=20
showing the url will display "smb:///" while the error message (if any)=
 will=20
show smb://.

I am going to try to figure out a testcase for this, dolphin is too big=
 for me=20
to even attempt to solve this bug.

Cheers!

--nextPart2219081.kFBWcbsFsg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJU4OzpAAoJEGCsZ2zsJAWeJlQQAL2h7rON3qdeifFkeMYQExvc
lwNFdv6Zs5ohFPcsQCZKk3Cea54CdYRK/Da8aEgIKyoLG3NWhQTrp95PBC85tKyu
8b40++r1dpHnkLIXAU88YgUHXSKUVQJO06MFa82B7Kqj4NIOd3B6r3bHiSjJcxgJ
nxkCqd3EiLJwm7AstciamQjkWrGJte7hwRqKetPX4wlaYb0/Q71nCZL5okbBttvm
lF6NKT9/+/6V2cHN3M26gbsZKoChglFwhFD4nWSFLpSScJWxNImjBD9s0710t3o5
WUAGGH39bvt87qBKyrv0pgImEGjd4e/3Z3epvO51hub70weQ53XePDbY/f6pEUA1
famxb96aNUS2l9K8lqf5ln/UjeDKOf/qM3QonnDyA9SAp9HdsMMpqNMS3o+qvmyd
EkALF26Ep8nCjhWUCtUxRKqu7a4XnSZPCYLpCQp9Gyi2W2Pf0QzNnWP6llRo2VOu
4x6gBeCKFx8ONyvdZJ9LJmRATcu7NvPMNaV2yBJFQ5lT7jGkDSB5m1L8+7Oxvp9b
sPSrR4gDycko0pdeLu6uuFh4N7IrtyfkVTJhUrq63EH4jG35EaNaxkN/y5IyoDTd
tX1/P4Mecw/PO8Ai5UMJB7PQSZxhTHSlLDXDx7o7x4K1X4Y96wsspSUWWU7RTJjH
fqXx4YY9EGqFOoRooWOv
=GyMC
-----END PGP SIGNATURE-----

--nextPart2219081.kFBWcbsFsg--


--===============6518237823627874725==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

--===============6518237823627874725==--