Colon in folder name followed by a number creates fatal error #25479

tflidd opened this Issue Jul 14, 2016 · 20 comments


None yet

7 participants

tflidd commented Jul 14, 2016

Steps to reproduce

  1. Create user1 and user2
  2. user1 shares folder share with user2
  3. user1 syncs share with desktop client
  4. user2 creates folder today 12:00

Expected behaviour

folder today 12:00 is synced or if colons are impossible in the OS it should be ignored.

Actual behaviour

Internal server error


Web server error log

2016/07/14 12:14:47 [error] 14916#0: *1128 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Unsupported operand types in /var/www/owncloud/3rdparty/sabre/uri/lib/functions.php on line 181" while reading response header from upstream, client:, server: _, request: "PROPFIND /remote.php/webdav/share/today%2012:00 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: ""

reported by user on the forum: (OC 9.0.3, client 2.2.2 on OS X), more details not known (yet)

I verified this on a rPI2:

Server configuration

Operating system: Raspbian 8

Web server: Nginx

Database: Mysql

PHP version: php 5.6

ownCloud version: 9.0.3

Updated from an older ownCloud or fresh install: 9.0.0

Where did you install ownCloud from: repo

Signing status (ownCloud 9.0 and above): good

It's a basic setup, no 3rd-party apps, no encryption, no proxy, no external storage.

Client 2.2.2 shows error (Ubuntu 16.04/OS X).


Hmmmm, indeed. I thought it was php-fpm specific but it also happens in my mod_php instance.

@PVince81 PVince81 added this to the 9.0.5 milestone Jul 14, 2016

It used to work in 8.1 => regression. I suspect it could be due to a Sabre lib update where URL handling might be different.

Will try and find where it broke.

@PVince81 PVince81 added the regression label Jul 14, 2016

stable8.2 is fine, stable9 is broken


Indeed, it's the update to Sabre 3 eacb24c

CC @DeepDiver1975

Let's see what needs adjusting


Hmmmm... I tried writing a test but the test will properly URL encode the colon.
However the desktop client doesn't.


Reproducible with a non-encoded colon:

% curl -D - -X MKCOL http://admin:admin@localhost/owncloud/remote.php/webdav/colon%2010:14

It seems Sabre URI uses parse_url from PHP and that one doesn't seem to like colons.

Ohhhh, it's even weirder: it's only with colon followed by numbers !

This works:

% curl -D - -X MKCOL http://admin:admin@localhost/owncloud/remote.php/webdav/colon%2010:abc

Found this:


This is with php5-5.6.23-1.1.x86_64

@DeepDiver1975 do you see this behavior with PHP7 ?

@PVince81 PVince81 changed the title from Colon in folder name creates fatal error to Colon in folder name followed by a number creates fatal error Jul 14, 2016

Two solutions:

  1. Patch + send PR upstream in Sabre URI to also encode ":" when not encoded (CC @evert)


  1. Ask the clients to encode colons in URLs

@DeepDiver1975 do you see this behavior with PHP7 ?

let me try this ...


same with php7


Can a regexp expert tell me how to adjust to also include the colon ? All my attempts failed...

These never seem to match the colon:
'/[^[:ascii:]:]/u',, '/[^[:ascii:]\:]/u', '/[^[:ascii:]\\:]/u',

guruz commented Jul 14, 2016

don't include the colon, it's where to body stores 💩


@PVince81 The regexes you've posted are negated by the ^, try '/(?:[^[:ascii:]]|:)/u' instead (the?:` makes the group non-capturing, and it either matches a non-ASCII character or a colon)

evert commented Jul 14, 2016

This would also escape the colon in the schema.

I think that PHP bug should be reopened though with better clarification and lining up with what rfc3986 says about this.

If we can get the PHP guys to confirm that it is indeed a bug, I think that that would be a better basis for creating the workaround for sabre/uri.

Make sure that whatever change you're making doesn't create incorrect result when the intention of the uri is to actually include a tcp port.


Any volunteer to report this upstream on the PHP bugtracker ? Possibly someone who already has an account there.

@PVince81 PVince81 modified the milestone: 9.0.6, 9.0.5 Sep 21, 2016
@PVince81 PVince81 modified the milestone: 9.0.7, 9.0.6 Oct 20, 2016

Workaround would be to have the clients url encode the colon.

But it seems indeed to be a PHP bug, see

@PVince81 PVince81 modified the milestone: 9.0.8, 9.0.7 Nov 30, 2016
@PVince81 PVince81 self-assigned this Dec 1, 2016
@PVince81 PVince81 added the blue-ticket label Dec 1, 2016
PVince81 commented Dec 1, 2016

Apparently the web UI properly encodes the colon, probably because we use encodeURIComponent which does that. That's why it does work in the web UI.

PVince81 commented Dec 1, 2016

Instead of patching Sabre\URI maybe patching Sabre\Request::getPath instead to pre-encode the colon so that when we pass it to Sabre\URI::parse it will work...

@PVince81 PVince81 referenced this issue Dec 6, 2016

Fix colon followed by number #26773

7 of 13 tasks complete
PVince81 commented Dec 6, 2016

WIP PR here that adds a test to reproduce the issue: #26773

The final fix will require upgrading sabre/uri after fruux/sabre-uri#9 is released

Kawohl commented Dec 8, 2016

This is also related: owncloud/enterprise#1692

@PVince81 PVince81 closed this in #26773 Dec 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment