Server: Regression: nested resource URIs broken on master

Created on 18 Apr 2017  路  5Comments  路  Source: nextcloud/server

Apparently #4138 broke routing for resources that have a nested URI, like foo/{id}/bar/{otherId}.

This causes problems in Mail for folder resources like /apps/mail/account/1/folder/xyz. The route now always returns 404. Route is defined here https://github.com/nextcloud/mail/blob/master/appinfo/routes.php#L68

@rullzer @nickvergessen ideas?

1. to develop bug high regression

Most helpful comment

Proposal: revert the commit and add that change only to the relevant resources ( I think it was group management?)

All 5 comments

For reference 31f9be7a75712e9f8b7831ed29397527f9fa8baf

31f9be7a75712e9f8b7831ed29397527f9fa8baf is the first bad commit
commit 31f9be7a75712e9f8b7831ed29397527f9fa8baf
Author: Roeland Jago Douma <[email protected]>
Date:   Wed Mar 29 11:03:53 2017 +0200

    Match slashes in ../{id} resource routes

    Fixes #2954

    Before we could match on <prefix>/{id} however if the id contains a /
    this would not match properly. But since we define the resource routes
    internally we now make sure that we match all chars (up until the ?).

    Signed-off-by: Roeland Jago Douma <[email protected]>

:040000 040000 0771074daaa3c63991819207c06383935d08991b 071970a6cc2fa145d2f42ae8c29490e863919b3d M      lib

Yay, as I said, it will break an app :-D

Proposal: revert the commit and add that change only to the relevant resources ( I think it was group management?)

Fine by me.
Altough I don't get really why it fails. Becaus the /{id} part is added to the end for resources automatically. So that regex should actually match correctly... because you are not adding anything beyond that.

Ah ok I get it. It is not because https://github.com/nextcloud/mail/blob/master/appinfo/routes.php#L68 doesn't match it is because https://github.com/nextcloud/mail/blob/master/appinfo/routes.php#L67 matches to much.

It slightly changes behaviour so I'll revert and have a different fix. Altough one can argue that if you register '/foo' before '/foo/bar' then it is expected to match on '/foo'.

Was this page helpful?
0 / 5 - 0 ratings