Hi Ryan, thank you!
>> I suspect that, opposed to sync 1.1, the syncserver does not simply work >> with the different Host: http header (and others) it receives being >> behind the reverse proxy. > > Right - the new sync uses request-signing so it's important that the > server's idea of its hostname matches with what the client sees. > > I'm not sure how to get `pserve` to respect the Host header and > associated environment flags. I'd suggest moving to gunicorn as > documented here: > > https://docs.services.mozilla.com/howtos/run-sync-1.5.html#nginx-gunicorn > > It knows how to interpret the Host, X-Forwarded-Proto etc headers and > re-construct the publicly-visible URL from behind a reverse proxy. I tried to do that, but I'm totally new to all that python web deployment, so bear with me and tell me if I should do things differently. In syncserver.ini section [server:main], I set use=egg:gunicorn. I then ran $ local/bin/gunicorn --paste syncserver.ini --log-level debug which yields the same error as above about public_url != application url. Seem like gunicorn does not do the desired reconstruction. For reference, here is what netcat receives if started behind the reverse proxy (instead of gunicorn): > $ nc -l 61282 > GET / HTTP/1.1 > Host: localhost:61282 > ... (User-Agent etc) > X-Forwarded-HTTPS: on > X-Forwarded-Port: 443 > X-SSL-cipher: DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) > Mac=SHA1 > X-Forwarded-For: 37.201.193.172, 37.201.193.172 > X-Forwarded-Host: qrdn.musca.uberspace.de > X-Forwarded-Server: qrdn.musca.uberspace.de > Connection: Keep-Alive > All documentation I could find about gunicorn is heavily tied to nginx, so perhaps apache is setting different X-Forward* Headers I might emulate with RequestHeader set ...? Jonathan Biegert _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
