Hard to debug HTTP 400 issue

seng · October 23, 2015, 6:40am

We have a site with millions of users developed using Yii 1.1, few users reported HTTP 400 when they interact with any link on the site.When we try to reproduce the the issue for the same user in our local development system, it works just fine for us.

When we checked the app log, it appears to be have users land on view page our item without the item Id missed out that causes 400 in one scenario.

I verified the referrer Urls and checked all the statements that redirects users to item controller, all of them have second param passed array with ‘id’ key present. Even if ‘id’ sets as null value, it should have generated 404, not 400. There are possibilities for the CController::createUrl() would have skipped the param, but Url manager is not configured at all in the app which means, urlFormat is get and no rules to consider when composing url from route.

This is one use case I observed, but for few other users every link they clicked land on our site raises HTTP 400 which makes me clueless. I tried with old browsers / new browsers for the same user, but I couldn’t reproduce any.

Noted:

CSRF token is disabled
UrlManger not configured (so default are assumed)
Rights extension is enabled.

The other thing that I have observed is, urls appear to be case insensitive, though I haven’t configured UrlManger at all. I’m not sure whether this has anything to do with 400, but I wanted to add.

Platform:

NGINX 1.0.14

PHP-FPM 5.4.22 w/XCache v1.3.2

MySQL 5.5.21

If anyone can shed some light on where to look for this issue, it would be helpful.

mdomba · October 23, 2015, 8:31am

It’s hard to help for this kind of problems without knowing all the details like how the error is generated and by looking at the code…

seng · October 23, 2015, 9:03am

Hi,

Thanks for the response. Please find the stack trace from the log file. In the Item/train action, I verified all the methods that redirects to view action and ensure that none of them can skip the Id param. I also done the same in the view/item/train.php view file.

But, somehow the Url get generated with out id param that leads to 400. I couldn’t deduce anything from this log.

Is it UrlManager component that throws exception.

Or it is rights component that generates 400.

How can I even reproduce this error in my system?

How the URL works with both cases while Urls are case sensitive by default?

The app has SSO integrated with Open source forum. Is it failed SSO session / expired session that causes the problem?

Is that wrong HTTP verb that causes the the Id param to skip and generate 400. I have no clue. I don’t have idea of where to start debugging. I have added Yii2 port of debug extension to get more details / insight of the data at the time of exception.

Please advise me on what code should I share so you can help me.


2015/10/19 16:06:41 [error] [exception.CHttpException.400] exception 'CHttpException' with message 'Your request is invalid.' in /path/to/app/framework/web/CController.php:336

Stack trace:

#0 /path/to/app/framework/web/CController.php(309): CController->invalidActionParams(Object(CInlineAction))

#1 /path/to/app/framework/web/filters/CFilterChain.php(133): CController->runAction(Object(CInlineAction))

#2 /path/to/app/framework/web/filters/CFilter.php(40): CFilterChain->run()

#3 /path/to/app/framework/web/CController.php(1145): CFilter->filter(Object(CFilterChain))

#4 /path/to/app/framework/web/filters/CInlineFilter.php(58): CController->filterAccessControl(Object(CFilterChain))

#5 /path/to/app/framework/web/filters/CFilterChain.php(130): CInlineFilter->filter(Object(CFilterChain))

#6 /path/to/app/framework/web/filters/CFilter.php(40): CFilterChain->run()

#7 /path/to/app/protected/modules/rights/components/RController.php(36): CFilter->filter(Object(CFilterChain))

#8 /path/to/app/framework/web/filters/CInlineFilter.php(58): RController->filterRights(Object(CFilterChain))

#9 /path/to/app/framework/web/filters/CFilterChain.php(130): CInlineFilter->filter(Object(CFilterChain))

#10 path/to/app//framework/web/CController.php(291): CFilterChain->run()

#11 path/to/app//framework/web/CController.php(265): CController->runActionWithFilters(Object(CInlineAction), Array)

#12 path/to/app//framework/web/CWebApplication.php(282): CController->run('view')

#13 path/to/app//framework/web/CWebApplication.php(141): CWebApplication->runController('Item/view')

#14 path/to/app//framework/base/CApplication.php(184): CWebApplication->processRequest()

#15 path/to/app//public/index.php(46): CApplication->run()

#16 {main}

REQUEST_URI=/index.php?r=Item/view

HTTP_REFERER=http://www.our-site.com/index.php?r=Item%2Ftrain&id=12345678&StaticTraining%5Bid%5D=32&yt14=Train

RomanSolomatin · October 27, 2015, 2:06pm

If you are running a Linux server, try "item/view" not "Item/view" route. Case is very important under Linux.

seng · October 27, 2015, 2:47pm

Thank you for all the helps. It took me around 7 days to identify the issue. Though I’m an amateur programmer, my experience on identifying the issue may help someone.

Application log was not enabled. runtime didn’t have proper permission to write the logs. I fixed it to have the errors logged.
The original stack trace was not sufficient to identify the route cause. I had to install this extension (https://github.com/zhuravljov/yii2-debug) to get more insights in the issue (Is it happening to specific user agents, specific time, etc)
I already did the basic checks about case sensitivity, action param binding, routes, but all they were good.
When I checked the debug log, 400 raised as soon they interact with a particular page and that too in 1 second. When I did the same, it never occurred to me.
I shared my findings with the original developer, that it’s very unlikely for the user to click on any link for the system to generate 400. I couldn’t find HTTP 302 before 400, so it is unlikely to generate from server.
When I started debugging, there was a Tour (Bootstrap) plugin that I always skipped when attempting to reproduce the issue. That was causing all sort of issues. Whenever I search for problematic code, I skipped the public dir (Yii2 style), and looked into protected dir alone.

7 He suggested me to check the library, there the url was hard-coded. Users, whoever guided through the tour encountered the issue. Most users skipped the tour (like mine) so it affected only few users.

I started reading the following two books to improve my debugging skills.