Page refresh issue, need to open the page manually again

Issue #1009 resolved
Sargis created an issue

After Disabling/Enabling the monitoring of a task, page refresh is not working on the browser (tested on Firefox).

Firefox showing a popup saying that it must resend the information sent before.

So refreshing functionality is not working after any post request !

If we click on try again button we see the 403 forbidden page with cookie check failed. If we click on Cancel button we see an empty page or Firefox goes into offline mode. I send images, for popup, for cookie validation field 403 forbidden.

The problem is that after clicking enable/disable button, monit makes a POST request. Webpage rendered after post request cannot be refreshed normally…

Solution is to redirect the page after the post request with response code 303 (known as Post/Redirect/Get, described here:

Otherwise instead of refreshing the page with http-equiv=”REFRESH”, it can be done via javascript by:

window.location = window.location.href;

Comments (8)

  1. Lutz Mader

    Hello Tildeslash,
    I build monit myself from the repository,
    but I get no data via the monit command line, only "cannot parse response".

    I think the response status 302 can not handled propper by src/http/client.c. After I removed #1009 from src/http/cervlet.c, every thing works well again.

    For your information only,
    with regards,

  2. Lutz Mader

    sorry, but the error response handling is stil broken with 5.30.0.

    For something like
    monit status unknown

    I got a response with something like this

    <html><head><title>400 Bad Request</title></head><body bgcolor=#FFFFFF><h2>Bad Request</h2>Service 'unknown' not found<hr><a href=''<font> size=-1>monit 5.30.0</font></a></body></html>

    But the used header said (in “client.c”, see “_parseHttpResponse”)

    HTTP/1.0 302 Moved Temporarily

    Therefore, the status is 302 and not 400 and the response will not parsed properly (based on “status < 300 || status == SC_MOVED_TEMPORARILY”).

    I checked “send_error“ (in “processor.c”) but can not find where the 302 came from, sorry.

    With regards,

  3. Lutz Mader

    Hello again,
    the problem come from “doPost” (in “cervlet.c”).

    A 302 header will append to the response all the time, see “set_status(res, SC_MOVED_TEMPORARILY);“

    This will not fit to the 400 sent in the body created by “send_error“ (in “processor.c”), I think.

    With regards,

  4. Log in to comment