get 403 error from time to time, but not always

I don’t know if this is the right forum for this kind of problem - if it is not, please point me to the right one.

I have installed a Yii application for a typical CRUD application for a client. This client reports me that he is facing 403 errors from time to time. I took a look into the log files and can confirm this:

This is the access.log sequence when everything goes ok: - - [29/Mar/2011:11:40:00 +0200] "POST /index.php/behandlung/create?tid=104 HTTP/1.1" 302 23 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20110319 Firefox/3.5.18" - - [29/Mar/2011:11:40:00 +0200] "GET /index.php/tier/104 HTTP/1.1" 200 2849 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20110319 Firefox/3.5.18"

So, after posting the form data of model “behandlung”, I get redirected (302) to the read-only page where the data is displayed. That’s the way it should be.

But sometimes (about 50% of the time!) this happens instead: - - [29/Mar/2011:11:37:04 +0200] "POST /index.php/behandlung/create?tid=56 HTTP/1.1" 403 196 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20110319 Firefox/3.5.18"

A 403 error on posting!

A few more points:

  • The client claims that although the Internet connection may be fragile from time to time (some kind of ADSL), it is just ONE model which has this problems: the model "behandlung", other models seem to have no problem.

  • I am not able to reproduce the problem from my place (solid Internet connection).

  • If the user posts the same form again (after entering the same data once again), it often works.

My question:

I am confused about the 403 error. I would suspect that if the client is facing connectivity problems, then ANY page would fail to load from time to time. But the request arrives at the Apache server and I can see the 403 in the logs. I do not understand this. In case of session timeout OSLT, I would be redirected to the login page, but no 403. So what does that mean?

Does anybody have ideas what could be happening? How can I diagnose further? I disabled the UrlManager to see if it maybe makes things worse (just a vague idea).

Check out the Definitive Guide about Logging. If the 403 occurs in Yii you might find helpful information about the nature of the problems in Yii’s logfiles.


– David

  1. Do you use HTTP Authentication? Like it’s often implemented with .htaccess file on Webserver level (Apache)?

  2. Does your application contain any code that could throw a CHttpException? Like using an access control filter etc.?

Sorry for the delay, I turned on trace mode and waited until the problem re-occurred. Today it did. Here are my findings so far:


[*]No, I don’t use HTTP Auth. However, I use Yii’s login facility: to access any page, you have to login first.

[*]No, my app does not throw any CHttpException. What’s more, in the cases where the 403 was thrown, the application runtime log did not log the slightest thing, although in trace mode. So I assume the request did not reach the index.php file at all (points to HTTP Auth problem?)

[*]Very strange: only ONE page seems to have the problem: the creation of a "behandlung" (request URL: something like


). More concisely, only the POST request (create or update) of entity "behandlung" throws a 403 sometimes (2 times out of 10 I get a 403, the other 8 times it goes ok), any other page does not.


The fact that it is always the same page (behandlung/create and behandlung/update) which produces the problem, seems to indicate that the application has a bug. "behandlung" is one of 4 models for the CRUD application, the other 3 models (with their respective controllers) do not show any problem. Anyway, it is not reproducible: the next time the POST would work. About each 5th to each 10th attempt throws a 403 with the "behandlung" entity.

On the other hand, in cases where the 403 occurs, nothing was logged (although in trace mode). The request seems not to reach the index.php file at all but was blocked beforehand. This in turn indicates that the Web server is causing the trouble. But why only with the "behandlung" entity?

Also, I doubt that there is a problem with the authentication code of the app because in the 403 cases the application seems to be involved at all (no logging). If the access control filter is the cause, then I would see something in the runtime logs, don’t I?

I am really confused big time. What can that be?

This is the .htaccess in the root directory (where the app’s index.php resides) - seems unsuspicious to me:

### zum Aktivieren in ".htaccess" umbenennen 

### entsprechende Anweisung auskommentieren 

### php 5.3 aktivieren ####

#AddHandler php53-fastcgi .php

### php 4.9 aktivieren ###

#AddHandler php4-fastcgi .php

### Konfiguration von php 5.2 ändern

### entsprechende Anweisung auskommentieren

<IfModule mod_php.c>

		php_value display_errors 1


To illustrate what’s being logged at “trace” level: each request begins in the log file with:

2011/04/05 11:19:42 [trace] [system.CModule] Loading "log" application component

in /var/www/web615/html/index.php (13)

2011/04/05 11:19:42 [trace] [system.CModule] Loading "request" application component

in /var/www/web615/html/index.php (13)

So, since logging is that "intense", I expect that every request should leave some trace in the runtime log file. Am I right?

Your assumptions sound correct, so the 403 seems to rather come from the webserver. You should also be able to tell who’s generating the 403 from the layout of the error page. Apache errors look different than Yii’s CHttpExceptions.

To me it sounds like there’s a (yet) unidentified layer involved, e.g. a proxy server or some load balancer.

AFAIK yes and if the 403 is caused by a application exception it should be logged – If possible you could make Apache logging more verbose by increasing the LogLevel and check Apache’s error log.


– David

After doing some extra analyses, it seems to me as if Mike was right: “To me it sounds like there’s a (yet) unidentified layer involved, e.g. a proxy server or some load balancer.”

I contacted the hosting provider. The hoster ( uses the mod_security module which could generate these 403 errors. Not sure so far, but the symptoms are compatible with this possible culprit: on some postings mod_security would decide that there was "evil" data posted and throws a 403. This could explain the apparently stochastic nature of this problem - it simply depends on what the user entered in the form.

So, I think this is not a Yii issue at all.