New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PROPFIND reply is not XML formatted #1098
Comments
I cannot reproduce the problem. |
Hello, Please find the client log below. I have replaced the actual server host name with some asterisks. Unfortunately I couldn't attach the entire log in one message, as it was too long for github. So it is split to 2 comments. First I created folder1 and folder1/folder2 but no files. It synced without any problems. Then I deleted them and did the same with other folder names and one file. So I had mappa1, mappa1/mappa2 and mappa1/mappa2/test2.txt. This time the error occured as expected. Reading through the log I have two comments:
Here are the relevant parts. First the good one: 10-15 13:34:20:558 csync_merge_algorithm_visitor: INSTRUCTION_NEW dir: folder1 ... then the one with the error: 10-15 13:35:04:862 _csync_merge_algorithm_visitor: INSTRUCTION_NEW dir: mappa1/mappa2 I would be very glad to help you with any further details, including remote access to server/client or whatever you might need. David Here is the full log: 10-15 13:34:07:396 "################## ownCloud hu_HU () 1.4.1" |
10-15 13:34:21:280 XX slotScheduleFolderSync: folderQueue size: 0 |
So it does a PROPFIND to check weather the directory already exist. It should not exist. So it should return a 404 error code. Here, the PROPFIND returns 200 OK. and is html instread of XML. Is there perhaps a proxy in the middle that is changing the 404 errors? |
No. It is a direct connection to an nginx server. Here is the full config: #server { # listen 80; # server_name cloud.example.com; # return 301 https://$server_name$request_uri; # enforce https #} server { # listen 443 ssl; listen 80; server_name cloud.*********.hu; # ssl_certificate /etc/ssl/nginx/cloud.example.com.crt; # ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key; # Path to the root of your installation root /var/www/*********/public_html/cloud.*********.hu/; client_max_body_size 10G; # set max upload size fastcgi_buffers 64 4K; rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect; rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect; rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect; index index.php; error_page 403 = /core/templates/403.php; error_page 404 = /core/templates/404.php; location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ ^/(data|config|\.ht|db_structure\.xml|README) { deny all; } location / { # The following 2 rules are only needed with webfinger rewrite ^/.well-known/host-meta /public.php?service=host-meta last; rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last; rewrite ^/.well-known/carddav /remote.php/carddav/ redirect; rewrite ^/.well-known/caldav /remote.php/caldav/ redirect; rewrite ^(/core/doc/[^\/]+/)$ $1/index.html; try_files $uri $uri/ index.php; } location ~ ^(.+?\.php)(/.*)?$ { try_files $1 = 404; include fastcgi_params; #fastcgi_param SCRIPT_FILENAME $document_root$1; fastcgi_param SCRIPT_FILENAME /public_html/cloud.*********.hu/$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT /public_html/cloud.*********.hu/; fastcgi_param PATH_INFO $2; #fastcgi_param HTTPS on; fastcgi_pass unix:/tmp/phpfpm-*********.sock; } # Optional: set long EXPIRES header on static assets location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ { expires 30d; # Optional: Don't log access to assets access_log off; } } |
So, instead of a 404 it returns a 200, that is: /core/templates/404.php What shall I do? I got the template of nginx config from here: |
If you use wireshark to see what happens, what is the actual html that is sent? Maybre if you commant the error_page lines? But i have not so much ideas about nginx configuration. |
OK, got it! In nginx the error page config line should be: With the equal sign you can modify the status code. E.g.: The OwnCloud documentation (http://doc.owncloud.org/server/5.0/admin_manual/installation/installation_others.html According to the nginx documentation (http://wiki.nginx.org/HttpCoreModule#error_page) with this setting the designated error handler determines the returned status code. So, now I changed to the easiest solution: It preserves the 404 code and sync works as expected. Could you please either correct your documentation or dix the error handler php to return proper error codes? Thank you very much for your efforts, great work and excellent support. I really appreciate the hard work of OwnCloud Team. David |
Thanks for the anlysis. Fixed the documentation accordingly. The updated version should be on the website in a few minutes. |
Expected behaviour
OwnCloud should upload (sync) files without errors.
Actual behaviour
Client drops "PROPFIND reply is not XML formatted" errors and does not upload.
Steps to reproduce
5, Sync starts and stops, then restarts and restarts again ... infinite loop. It says "PROPFIND reply is not XML formatted"
If you put a file to test1 folder after step 3 (e.g. ~/test1/readme1.txt) and then follow with step 4, then everything works as expected! So there must be some problem with the empty parent folder.
Server configuration
Operating system: Ubuntu Server 12.10
Web server: Nginx 1.2.1
Database: MySql 5.5.32-0ubuntu0.12.10.1
PHP version: 5.4.6-1ubuntu1.4
ownCloud version: 5.0.12-0
Client configuration
Browser: Google Chrome latest
Operating system: Ubuntu Desktop 12.04
Logs
Web server error log
N/A (available on request, if relevant)
ownCloud log (data/owncloud.log)
{"app":"PHP","message":"Comments starting with '#' are deprecated in Unknown on line 1 at Unknown#0","level":4,"time":"2013-10-14T19:38:21+00:00"}
{"app":"PHP","message":"Comments starting with '#' are deprecated in Unknown on line 1 at Unknown#0","level":4,"time":"2013-10-14T19:38:54+00:00"}
{"app":"PHP","message":"Comments starting with '#' are deprecated in Unknown on line 1 at Unknown#0","level":4,"time":"2013-10-14T19:39:27+00:00"}
Browser log
N/A (available on request, if relevant)
The text was updated successfully, but these errors were encountered: