monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reverse proxy support


From: Martin Pala
Subject: Re: Reverse proxy support
Date: Tue, 06 Feb 2007 22:52:07 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061219 Iceape/1.0.7 (Debian-1.0.7-2)

Josh Kelley wrote:
I think that there may be problems with the redirect handling.
According to the HTTP standard (RFC 2616 section 14.30), redirects
must be absolute (i.e., including the http://hostname/).  Similarly,
do_redirect's comments indicate that the URL must be absolute.
Redirects are not absolute with Monit 4.8.2 (which redirected using
URLs with leading /s) or in CVS (which redirects using URLs without
leading /s), but relative redirects seems to work anyway.

Yes, you are right. I have spotted it as well during testing of the mentioned buttons, which lead to the relative redirect modification. This is not conforming to RFC, but since monit is using this approach for some time (with leading '/'), and for reasons described bellow in point 2 i though that this change will be less dangerous for next release then assembling the absolute URL - since clients which accept relative redirects should still work. To make sure that it won't break i tried few browsers (Firefox, Seamonkey/Iceape, Konqueror, Internet Explorer) which all worked without problems.

 I don't
know if it's worth fixing this right now to make it
standards-compliant.  (I don't see a way to determine the absolute URL
to use in all circumstances without tracking the Host: parameter of
the HTTP request and/or tracking which interface the request was
received on.)

We should fix it in the (near) future ... i though about two possible solutions:

1.) either implement POST method in monit http and don't use GET for forms, which should eliminate the need for redirects at all (preferred solution)

2.) or reuse the Host header from the request (Host is mandatory according to HTTP/1.1). If The Host header won't be available, then the problem could become tricky, since monit can be placed behind firewall/NAT and the interface->address/hostname which can be read from incoming socket may be different then what client is using for monit connection => the redirect to invalid hostname/address can break the session.

Thanks :)

Martin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]