httpd behind proxy

Дилян Палаузов Dilyan.Palauzov at
Thu Jun 21 14:12:13 EDT 2018


Nginx being proxy removes the Etag when sub(stutions) are involved (,242807,242809#msg-242809).

If Nginx is used as proxy and it returns ETags on GET, then most probably the backend runs already on https and has the right hostname, so that nginx doesn't need any rewritings.

Now, if a client sends Forwarded header and httpd, not being behind a reverse proxy, interprets it, replacing the schema and hostname in the answer, e.g the URL: in /freebusy/user/... request, then the behaviour of httpd by interpreting the header will be correct: the client asked for troubles and got troubles.  The troubles however do will not happen if httpd is behind a proxy and the proxy inserts Forwarded, as only the last Forwarded is supposed to be interpreted.  Irgnoring in this case Forwarded, as this is anyway now the case, is also correct.

So I propose removing the checks in imap/http_proxy.c:http_proto_host() for config_mupdate_server and proxyservers.


On June 20, 2018 7:10:45 PM GMT+02:00, Ken Murchison <murch at> wrote:
>On 06/20/2018 12:23 PM, Dilyan Palauzov wrote:
>> Hello,
>> I want to run cyrus-httpd behind proxy, making it to listen to 
>>  It then sends on /freebusy/user/me URL: 
>> , which I don't want.  If I tweak 
>> the front-end, nginx, to rewrite -> my hostname, Nginx is 
>> smart enogh and removes the ETags sent by cyrus/httpd, so this 
>> approach does not work.
>> Then I decided to insert "Forwarded: host=my host; proto=https" 
>> header, however imap/http_proxy.c:http_proto_host handles the 
>> Forwarded header only
>>     if (config_mupdate_server && 
>> config_getstring(IMAPOPT_PROXYSERVERS) &&
>>         (fwd = spool_getheader(req_hdrs, "Forwarded"))) {
>>         /* Proxied request - parse last Forwarded header for proto
>> host */
>> What is the rationale behind interpreting Forwarded only when 
>> mupdate_server and proxyservers are set?
>I don't recall if I had any specific reason in mind when I added that 
>check.  The downside of removing the check is that a client can do as 
>you plan to and can cause the server to change URLs in replies.  I'm
>a security expert, but this seems like something we don't allow a
>to do.
>I know that we (FastMail) run Cyrus behind nginx and this hasn't become
>an issue, unless our ops guys have patched Cyrus or found a different 
>way to handle this in Nginx.  Bron may know, once he wakes up.

More information about the Cyrus-devel mailing list