403 errors on prev/next and 2nd pages

[thernlund]

I've hunted around and not found a clear answer.  So here's the issue...

In my Apache logs I get 403 error in two cases (that I've discovered so far).  In the first case, the error is logged as follows...

Code Select Expand

xxx.xxx.xxx.xxx - - [03/Mar/2012:07:36:35 -0700] "GET /index.php/topic,148.0/prev_next,next.html HTTP/1.1" 403 369 "http://xxxyyy.net/index.php/topic,148.0/topicseen.html" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"


These are logged ONLY for Firefox, and always the same in that it's with the "prev_next,next.html" link.  Through some research, I came to attribute this to FF doing prefetching.  Ok, fine.  A little more research lead me to this fix, which stops producing these 403 errors...

In index.template.php...

Code (find) Select Expand

// If we're viewing a topic, these should be the previous and next topics, respectively.
if (!empty($context['current_topic']))
echo '
<link rel="prev" href="', $scripturl, '?topic=', $context['current_topic'], '.0;prev_next=prev" />
<link rel="next" href="', $scripturl, '?topic=', $context['current_topic'], '.0;prev_next=next" />';


Code (replace) Select Expand

// If we're viewing a topic, these should be the previous and next topics, respectively.
if (!empty($context['current_topic']))
echo '
<link rel="prev" href="', $context['links']['prev'], '" />
<link rel="next" href="', $context['links']['next'], '" />';



That stops the 403 errors in the logs.  But... the link appears to be exactly the same.  I can't for the life of me figure out what could be different where one would produce 403s and the other wouldn't.

Which makes me also wonder... am I breaking the board functionality somehow?  I know SMF attempts to detect prefetching in order to prevent the read/unread data from going wonky, among other things.  So have I broken that or something else (although I can't see how)?

Adding to my confusion, I have another board on another server that does not produce 403s at all with the original code in place.  WTF?


In the second case, I get the same issue described above with the page numbers.  Log line is as shown...

Code Select Expand

xxx.xxx.xxx.xxx - - [06/Mar/2012:13:05:39 -0700] "GET /index.php/topic,16.25.html HTTP/1.1" 403 369 "http://xxxyyy.net/index.php/topic,16.0.html" "Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"

I haven't done anything to solve that yet, but I suspect the same fix will do it.

Any ideas what's up here?

Thanks a bunch.


-T.

[kat]

Just a "HUH?" from me.

html? How's that getting in there?

Unless I've missed something (Which is very likely), that's kinda weird.

Do you have PrettyURLs any mods installed?

[Illori]

no but it looks like they are using Search engine friendly URLs instead which is a built in feature

[thernlund]

Search Engine Friendly URLs.

Admin --> Configuration --> Features and Options


-T.

[thernlund]

Looks like I did break it with my 'fix' above.  Once implemented, errors began filling the logs...

http://xxxyyy.net/index.php?action=post;topic=210.0;last_msg=1739
8: Undefined index: links
File: /srv/default/public_html/Themes/default/Post.template.php (html_above sub template - eval?)
Line: 163

http://xxxyyy.net/index.php?action=post;topic=210.0;last_msg=1739
8: Undefined index: links
File: /srv/default/public_html/Themes/default/Post.template.php (html_above sub template - eval?)
Line: 162

These two errors are produced when clicking the Reply button on a given topic.  I undid my changes and no more errors.

Soooo... anyone?  Ideas on the 403 errors?


-T.

[kat]

That damned "eval" thing is masking the real error, I'm afraid.

Try going to Admin>Server settings and enabling "Disable evaluation of templates".

Clear-out the error-log and see what new ones you get.

[thernlund]

Ok.  Tried it.

Pretty much exactly the same error, but with index.template.php. 

But I already knew that.  index.template.php is the file I made the original changes to, described in the OP.  Undoing the changes stopped the error.

So the question is no longer the one concerning the changes and if I broke something.  The question concerns the 403 errors in my Apache logs.  Why are they there, how to eliminate them? 

They'd be no big deal except they're greatly increasing the log size, which isn't acceptable.  Some relevant points of interest...

• I have another forum I administer that does not produce these 403s in the Apache logs, and has the same software installed.
• This isn't theme related, as the default theme produces these 403s too.

-T.

[kat]

Generally speaking 403 errors are about permissions. A 403 is "Forbidden", kinda thing.

So... something you're doing requires a permission that you don't have.

Do you have full ownership (CHOWN) of the files on your site?

[thernlund]

Yes.  I own the server, and have full root access.  But a more relevant question is does the Apache account has full access to the relevant files.  The answer to that is yes, it does.

Again, as per the OP, I attribute these 403s to Mozilla Prefetching.  SMF actively prevents prefetching in order to maintain correct read/unread data, among other things.

So I guess I misspoke in post #6.  I do know WHY they're there on some level.  In order for SMF to work properly, it must disallow prefetching.  But what I don't know is why are they logged on this forum and not my other forum?


And here's another problem (I think)... these 403s in the logs get seen by Fail2Ban.  If a given IP produces enough to reach Fail2Ban's threshold, the members IP will get banned from the server.  Bad juju.


-T.

[kat]

Adding to my confusion, I have another board on another server that does not produce 403s at all with the original code in place.

Different server configs? Different PHP versions? Different permissions, somehow?

[thernlund]

Likely different configs.  But I'm just not seeing where.

What I'm really looking for here is someone who has seen this or something similar and has some insight as to what it might be.  I run many websites and have only seen this with SMF.


-T.

[kat]

This is really weird. So, I'm fishing, a bit...

You mention Firefox's prefetching.

What happens if you use Opera, or something?

[chavez243ca]

Exact same here, 403 caused by FF prefetching and the 403s in the logs are triggering OSSEC to block IPs.

Not seeing this with Chrome, Safari, IE, Opera - only FF.

Have had some users disable prefetch in FF and that has solved the issue for them.