Base url not always being applied (and other 404s)

Hi

I've been passing nginx logs through ossec and onwards into splunk.
In the process I find a few strange and sometimes interesting things.

One thing I see is a large number of 4XX messages, similar to the following:

GET /dhis-web-reporting/index.action HTTP/1.1" 404 0

The actual url should be prefixed with /dhis, like:

GET /dhis/dhis-web-reporting/index.action

I have not heard any complaints from users (fact is I don't know the
users on this machine) so I am not sure quite what effect this is
having on the user experience, but there does seem to be a number of
places in the application where the incorrect urls are being formed.
I've extracted and listed the ones which appear in my log file below:

/dhis-web-commons-about/redirect.action
/dhis-web-commons/css/account.css
/dhis-web-commons/css/login.css
/dhis-web-commons/css/widgets.css
/dhis-web-commons-security/login.action
/dhis-web-commons/security/login.action
/dhis-web-commons/security/login.action;jsessionid=XXXXX
/dhis-web-commons/security/recovery.action
/dhis-web-dashboard-integration/index.action
/dhis-web-dataentry/index-action
/dhis-web-reporting/displayViewDataCompletenessForm.action
/dhis-web-reporting/index.action

I wonder is there any kind of due diligence code grep we can do to
track down where these bad requests are being initiated?

There is another possibility of course that these URLs may have been
cached in user's browsers prior to the system being reinstalled. In
fact I suspect that is most probably the case.

ยทยทยท

On 22 April 2015 at 09:37, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi

I've been passing nginx logs through ossec and onwards into splunk.
In the process I find a few strange and sometimes interesting things.

One thing I see is a large number of 4XX messages, similar to the following:

GET /dhis-web-reporting/index.action HTTP/1.1" 404 0

The actual url should be prefixed with /dhis, like:

GET /dhis/dhis-web-reporting/index.action

I have not heard any complaints from users (fact is I don't know the
users on this machine) so I am not sure quite what effect this is
having on the user experience, but there does seem to be a number of
places in the application where the incorrect urls are being formed.
I've extracted and listed the ones which appear in my log file below:

/dhis-web-commons-about/redirect.action
/dhis-web-commons/css/account.css
/dhis-web-commons/css/login.css
/dhis-web-commons/css/widgets.css
/dhis-web-commons-security/login.action
/dhis-web-commons/security/login.action
/dhis-web-commons/security/login.action;jsessionid=XXXXX
/dhis-web-commons/security/recovery.action
/dhis-web-dashboard-integration/index.action
/dhis-web-dataentry/index-action
/dhis-web-reporting/displayViewDataCompletenessForm.action
/dhis-web-reporting/index.action

I wonder is there any kind of due diligence code grep we can do to
track down where these bad requests are being initiated?