Weird caddy + grav + ios + https problem

I have been running Caddy for a while now, and I’m currently running 0.10.2 version. I am serving a number of sites, local flat files, php, proxied - and all except one are working perfectly.

The exception is running the Grav CMS. This is almost perfect as well (leaving aside that the site contents are in an early stage of development). It works everywhere except on iOS when using https. It’s fine on Windows or Android, using any browser, It’s fine on iOS if I am only serving http without any automatic https. But if I am serving https it fails - but only on iOS, with any browser.

In this case it simply hangs, and eventually iOS says the server stopped responding. If I look at the Caddy log, it just show the initial request, and no other - but this request is repeating. If I try to trace the packets, I see a request from iOS, then a response from Caddy, then a little later a repeat of the same. I can’t read the packets because - well, https, right?

I am at a loss what to try next. Any suggestions?

Thanks,
Paul

Here’s my caddyfile.conf (the site concerned is tetrahedral.audio):

####################################################################################
####################################################################################

cassland.org, 
www.cassland.org {
	root ..\cassland.org\html
	browse /Album
	browse /images
	browse /sounds
	browse /Varicam

# "startup" seems to hang on Windows, so I made php-cgi a service instead.
	fastcgi / 127.0.0.1:9123 php

# proxy random image generators to Apache which knows what to do with them:
	proxy /images/QCavi.jpg localhost:81 {
		transparent
	}
	proxy /images/PJavi.jpg localhost:81 {
		transparent
	}
	proxy /images/FireDog.jpg localhost:81 {
		transparent
	}

# password for Cherwell Singers pages:
	basicauth /CherwellSingers cherwell xxxxxxxxxxxxx

	log .\Logs\CLaccess.log
	errors .\Logs\CLerror.log {
		404 404.html
#		404 New404.html
	}
}

####################################################################################

michaelgerzonphotos.org.uk, 
www.michaelgerzonphotos.org.uk {
	root ..\michaelgerzonphotos.org.uk\html
	log .\Logs\MGaccess.log
	errors .\Logs\MGerror.log
}

####################################################################################
# Viv's Pots sites:

viviensieber.eu, 
www.viviensieber.eu {
	redir 302 {
		if {path} is /
		/ /vivspots
	}
	redir /vivspots https://vivien158.wixsite.com/vivspots
	root ..\emptysite
	log .\Logs\VSaccess.log
	errors .\Logs\VSerror.log {
		404 New404.html
	}
}

####################################################################################
# A new Serious Discussion site for EGF refugees:

seriousdiscussion.cassland.org {
	root ..\SeriousDiscussion
	fastcgi / 127.0.0.1:9123 php
	log .\Logs\SDaccess.log
	errors .\Logs\SDerror.log
}

####################################################################################
# SMF and phpBB test sites:

qc-test-forum.cassland.org {
	root ..\SMF-v2.0
	fastcgi / 127.0.0.1:9123 php
	log .\Logs\QCaccess.log
	errors .\Logs\QCerror.log
}

# testing proxying phpBB (for certificate at EGF):

eg-test-forum.cassland.org {
	proxy / http://eg-test-forum.cassland.org:88
	log .\Logs\PTaccess.log
	errors .\Logs\PTerror.log
}

http://eg-test-forum.cassland.org:88 {
	root ..\EvaTest
	fastcgi / 127.0.0.1:9123 php
	log .\Logs\EGaccess.log
	errors .\Logs\EGerror.log
}

####################################################################################
# Proxied sites (simple):
# (because these sites are polled continuously, the access logs are disabled)

mail.cassland.org {
	proxy / http://mail.cassland.org:8800 {
		transparent
	}
#	log .\Logs\WMaccess.log
	errors .\Logs\WMerror.log
}

deluge.cassland.org {
	proxy / localhost:6967 {
		transparent
	}
#	log .\Logs\DLaccess.log
	errors .\Logs\DLerror.log
}

emby.cassland.org {
	proxy / http://emby.cass.dom:8096
	log .\Logs\EMaccess.log
	errors .\Logs\EMerror.log
}

owncloud.cassland.org {
	proxy / http://owncloud.cass.dom {
		transparent
	}
	log .\Logs\OCaccess.log
	errors .\Logs\OCerror.log
}

####################################################################################
# Magnolia authoring is proxied directly to TomCat:

magnolia.cassland.org {
	rewrite / /magnoliaAuthor
	proxy / localhost:8080 {
		transparent
	}
	log .\Logs\M3access.log
	errors .\Logs\M3error.log
}

####################################################################################
# Magnolia sites are proxied via Apache which does the complicated proxy stuff:

www.ambisonic.info, 
ambisonic.info {
	proxy / localhost:82 {
		transparent
	}
	log .\Logs\AIaccess.log
	errors .\Logs\AIerror.log
}

www.studio.cassland.org, 
studio.cassland.org {
	proxy / localhost:83 {
		transparent
	}
	log .\Logs\SSaccess.log
	errors .\Logs\SSerror.log
}

www.house.cassland.org, 
house.cassland.org {
	proxy / localhost:84 {
		transparent
	}
	log .\Logs\CHaccess.log
	errors .\Logs\CHerror.log
}

####################################################################################
# Test versions of TA website:

hugo.cassland.org {
#	root ..\Hugo\public
	root ..\Hugo
	basicauth /admin pwhodges xxxxxxxxxxxx
#	hugo .\ ..\Hugo\admin
	hugo
	log .\Logs\TAaccess.log
	errors .\Logs\TAerror.log {
#		404 404.html
		404 New404.html
	}
}

respond.cassland.org {
	root ..\Respond\app\public
# rewrite all for files and directories that do not exist to index.php;
# also add .html for friendly URL handling:
	rewrite  {
		to {path} {path}/ {path}.html /index.php
	}
	fastcgi / 127.0.0.1:9123 php
	log .\Logs\TAaccess.log
	errors .\Logs\TAerror.log {
#		404 404.html
		404 New404.html
	}
}

grav.cassland.org:80,
tetrahedral.audio, 
www.tetrahedral.audio {
	root ..\tetrahedral-audio
	fastcgi / 127.0.0.1:9123 php
	gzip
# Begin - Security (provided by grav installation)
	# deny all direct access for these folders
	rewrite {
		r	/(.git|cache|bin|logs|backups|tests)/.*$
		to	/403
	}
	# deny running scripts inside core system folders
	rewrite {
		r	/(system|vendor)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat)$
		to	/403
	}
	# deny running scripts inside user folder
	rewrite {
		r	/user/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$
		to	/403
	}
	# deny access to specific files in the root folder
	rewrite {
		r	/(LICENSE.txt|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess)
		to	/403
	}
	status 403 /403
# End - Security
# global rewrite (should come last)
	rewrite {
		to {path} {path}/ /index.php?_url={uri}&{query}
	}
	log .\Logs\TAaccess.log
	errors .\Logs\TAerror.log {
#		404 404.html
		404 New404.html
	}
}

####################################################################################
# Placeholder for unimplemented sites:

#tetrahedral.audio, 
#www.tetrahedral.audio, 
refety.net, 
www.refety.net, 
cluthly.com, 
www.cluthly.com {
	root ..\emptysite
	log .\Logs\NULaccess.log
	errors .\Logs\NULerror.log {
		404 New404.html
	}
}

####################################################################################
####################################################################################

Your Grav conf looks good to me.

I actually went ahead and set up Grav again from scratch to try test against a 100% vanilla installation, and realised the issue is with iOS and I don’t have an iPhone handy :confused:

Does your error occur with https://grav.whitestrake.net?

Thanks for the trial site; I can see your site just fine. So I installed a completely vanilla copy of grav-admin on my server without changing a single setting, and the problem remains the same.

I guess I should update Caddy to 0.10.3, which I’ve just noticed (I’m on 0.10.2). The only other things I haven’t said are that I am running Caddy on Windows Server 2012, and that I have fully-functional IPv6 (internal and external - alongside IPv4, of course).

As this only happens with Grav, I guess it’s really a Grav problem; but OTOH it only happens on my server, so it’s my server’s problem! Whatever; it’s an interaction, and I still don’t have a clue just where that interaction is causing the failure. I suppose I can try disabling IPv6 for that domain name - but my Android connected using IPv6 just fine (for some reason Windows 10 chose IPv4 when I tested).

Paul

PS - updating Caddy made no difference, as I expected.

Hmm. I don’t know if you have a spare Windows 2012 server (tends to be a bit trickier than spare Linux servers), or can afford to take the other sites down for a short test, but it might be worth trying to run Caddy with only Grav in the Caddyfile, based off the template I used for my trial site (examples/Caddyfile at master · caddyserver/examples · GitHub).

Although I can’t see what could possibly have been done incorrectly, that would also cause this rather specific issue. Is it just one iOS device or many?

For reference grav.whitestrake.net is running on Ubuntu 16.04, Caddy 0.10.3, with IPv4 (no IPv6).

If you can narrow it down to the simplest reproducible, it might be worth throwing up on the Github issues and seeing if anyone else can replicate it.

I see this on several iOS devices, all running v10 (I haven’t tried v9, which I will when I can pinch my wife’s old phone).

I have another Windows Server 2012 running (and a WS 2016 and a CentOS 7 for that matter), so I’ll do a test on that. I guess if the problem shows there, it means that Windows+Caddy+Grav is the distinct problem. If the problem shows again I should then try running it in Apache on that server to see if I can implicate or exonerate Caddy as well.

There may be a delay of a few days before I can do those tests, as I have other more urgent matters to deal with this week.

Meanwhile, I have a simple workaround. Grav is running, in Caddy, using only http, and the “real” domain names are attached to a separate site (in the same Caddy) which proxies to it. That works just fine, and will do for the time being.

Paul

1 Like

Oops - my workaround isn’t perfect. It’s OK for the site, but if I attempt to log into the admin page I get “invalid security token”. Specifying the proxy as “transparent” makes a forwarding loop happen. There’s probably a clue there, but I can’t get my head round it right now.

Paul

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.