Anyone know how to log for instances where a user receives the "page not found" message

[CharlesH]

I'm interested in knowing if the log file can record details of when a user receives the "page not found" response generated by Confluence.

I've looked at the logging properties in the admin screen, and checked the Confluence documentation, but nothing so far suggests how to achieve this.

We do have Google Analytics available on our Confluence instance, but I'm ruling out the option of a custom event to log this in GA. I would like to which users are receiving the "page not found" message, and GA gathers data anonymously.

Thanks in advance.

[Jason Hensler · Accepted solution]

Mathew's link is correct about the functionality of the 404 page but, this can also be effected by how you are linking your webserver to your confluence instance. I have setup apache to use mod_jk to connect with confluence and mount the worker as /confluence. Anything under the url of /confluence will get the confluence 404 error page because, all of the traffic is forwarded to the tomcat server. I think the same would be true if you were directly hitting the tomcat server, anything under the context url set in your server.xml file would get confluences 404 page. (note I'm on version 5.3)

In a roundabout way you could see usernames by enabling confluence access logging (see here ), You would then have to match up the timestamp on the 404 error from you webservers log with the timestamp on the access log. I would think scripting it would be possible but, is probably far from perfect. If you could add the response code to the confluence access log that would get you what you want but, I don't know if it's a possible.

[Matthew J. Horn]

For 404s, you will need to look at your web server logs.

[CharlesH]

Thanks Matthew.

I have a side question related to this.

On our test instance, the "page not found" message is clearly being generated by Confluence. Sure enough this is reported by Firebug as a 4040, but it offers the user some alternatives to the original page, suggesting that the page may have been renamed or moved. Also present is the usual Confluence UI, so the user can search again or browse to another part of the wiki space.

On our production instance the 404 is clearly being generated by Apache, which we have sitting in front of Tomcat, so I can see that this would be tracable using the web server logs.

Ideally we'd prefer to go with the managed response that Confluence generates. If that can trigger a log message too, so much the better.

So I guess the side question is, do you know what might explain the difference in behaviour between the two instances? My IT infrastructure guys say that the server set-ups are the same, but equally, the administration settings are identical too. Both instances are running Confluence 5.0.2.

[Matthew J. Horn]

AFAIK (and maybe someone with more IT knowledge can chime in), you'll get the web-server's 404 page (the Apache one) when you make a request that Apache recognizes as missing. You'll get the Confluence error page when your request resolves at least as deeply as the space, but then does not resolve to a page.

I suspect this has something to do with the way Confluence's internals parse requests and generate responses. Essentially, the web server catches requests that don't meet some minimum requirements.

Here's an example that illustrates what I mean.

Given this bogus URL (the "ddd" at the end causes the error):

http://devcenter.verivo.com/display/ddd

I get the web server's 404 page. Notice that the space name is not valid; the web server catches it before trying to resolve the request.

Given this bogus URL:

http://devcenter.verivo.com/display/doc/Using+the+Akula+SDKddd

I get Confluence's 404 page. In this case, the space is correct, but the page name is bogus. The web server doesn't catch it but Confluence does.

Not sure if this helps, but I'm trying to piece together my (meager) knowledge of the Confluence architecture. I know Atlassian's doc does talk a little about how Confluence and the various appserver/webwork/velocity/etc modules interact, but I haven't got time to look into it just now.

All that being said, I'm pretty sure there's a way to override the default web server error handler and instead use the Confluence error handler. I haven't personally done that, yet, but I guess I'll add it to my list of things to do.

[Matthew J. Horn]

This page has more info:

https://jira.atlassian.com/browse/CONF-9747

[CharlesH]

Thanks Matthew & Jason. We're investigating further. I'll post back with what the issue is, assuming we can get to the bottom of it!

[CharlesH]

So the side issue of why we were seeing the Apache 404 came down to a proxy server setting apparently. Jason's explanation of how Confluence handles 404 responses was helpful in giving us a fuller understanding though.

In case it helps anyone else, sitting in the Confluence directory is a 404.vm file. This could be modified to raise a GA event and I guess the username of the current user could be passed as a custom variable. Goes against the grain a little bit, as GA tracking is normally anonymous, but maybe in this case the exception is okay.