Nextcloud proxy connection timesout

7 January 2018, 23:34
I have set up a new nextcloud server, and use hiawatha as a reverse proxy.
It worked good for a while, but syncing does not work always and now logging in times out.

I try to paste some logging, but this forums thinks its spam.

Should I send you a complete tcpdump file?
7 January 2018, 23:39
error log says:

Sun 07 Jan 2018 23:38:09 +0100|Reverse proxy timeout for

but tcpdump show a lot of activity
8 January 2018, 21:31
config is this:
VirtualHost {
Hostname =
ReverseProxy !^/.well-known/ 10
RequireTLS = yes
TLScertFile = /etc/letsencrypt/live/
WebDAVapp = yes
WebsiteRoot /var/www/hcs
#PreventCSRF = yes
PreventSQLi = yes
PreventXSS = yes
RandomHeader = 250 # anti decryption on https listening
UseToolkit = block_pma

UrlToolkit {
ToolkitID = block_pma
# Match ^/phpMyAdmin/.* DenyAccess
MatchCI phpMyAdmin/.* Ban 3600
MatchCI /Admin Ban 3600
Hugo Leisink
11 January 2018, 11:44
Anything weird in the logs of the backend webserver? Like bad requests ?
13 January 2018, 23:37
I have been tcpdumping sessions that go well, and that give errors.

Small files are uploaded fine. Larger files are not via the Hiawatha reverse-proxy. They are going fine without the proxy inbetween.

When Hiawatha is in between all goes well, until a MOVE command by the client should be issued.
But when dumping between hiawatha and backend I never see that MOVE command arrive.

:This is the move command that should be issued:
MOVE /remote.php/dav/uploads/hanscees/947574611/.file HTTP/1.1
Destination: //remote.php/dav/files/hanscees/artificialintelligencewithpython.pdf
Content-Type: application/octet-stream
OC-Async: 1
OC-Total-Length: 33296983
X-OC-Mtime: 1514836043
Authorization: Basic aGFuc2NlZXM6TGluemlzbGllZjQwJCQ=
User-Agent: Mozilla/5.0 (Windows) mirall/2.3.3 (build 1) (Nextcloud)
Accept: */*
Cookie: oc_sessionPassphrase=b863Pstz43hBEKKvGVk5%2B3%2BxAvBJPDuI9lSjnWSredcj1bNieKX56Y5TjEPya3%2B%2BBoy%2FLcVlpjGrXe0Nm0KOidLQ%2BfP8DRwo%2FjzNlO5vUJPRXN5TY5vJbqzJiYqUa99u; nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true; ocpm3gq71w2w=44357555f360c1bb0c767e9c697343a1
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: nl-NL,en,*

then the client says:
server replied: Not Found`13-1-2018 22:56:43, artificialintelligencewithpython.pdf,

13 January 2018, 23:42
the usual dav methods that are used when uploading a file are:

PROPFIND, answer TTP/1.1 207 Multi-Status
GET /ocs/v1.php/cloud/activity?page=0&pagesize=100&format=json HTTP/1.1
GET /ocs/v2.php/apps/notifications/api/v1/notifications?format=json HTTP/1.1

PROPFIND /remote.php/dav/files/hanscees/ HTTP/1.1 and again multistatus
MKCOL /remote.php/dav/uploads/hanscees/947574611 HTTP/1.1
PUT /remote.php/dav/uploads/hanscees/947574611/00000000
PUT /remote.php/dav/uploads/hanscees/947574611/00000001
PUT /remote.php/dav/uploads/hanscees/947574611/00000002
PUT /remote.php/dav/uploads/hanscees/947574611/00000003

then the move command should follow.
15 January 2018, 21:55
got it.
Dav uses a dotfile for large files and Hiawatha blocks this.
so this fixed it:
AllowDotFiles = yes
Hugo Leisink
15 January 2018, 23:27
Well done!! Sorry for the strict security in Hiawatha.
16 January 2018, 20:55
Isn't there a way to allow a dotfile in move, but not in download? If you allow dav in the config it might automagically allow move a putfile?
Just a though.
Hugo Leisink
17 January 2018, 19:37
No, allowing access to dotfiles is for all HTTP methods.
This topic has been closed.