Jeff Thanks for the response. My problem is that 400 is what should be seen by the client. These are truly BAD_REQUESTs. The problem is that they are being reported to the client as 200s. LIke it was set to 200 AFTER httpd already built the response header with 400.
The error log has nothing. We're running at warn. I can go to debug and see what I see. Thanks Tom On Fri, Oct 17, 2014 at 1:06 PM, Jeff Trawick <traw...@gmail.com> wrote: > On Fri, Oct 17, 2014 at 12:10 PM, Tom Purcell < > tpurc...@chariotsolutions.com> wrote: > >> Hello >> >> We have an application that consists of REST endpoints on a jboss >> server(5.1.0) fronted by Apache httpd(2.2.15). When a client makes a bad >> request it usually gets the expected 400 http response code but sometimes >> the client sees a 200. This happens sporadically. Two days ago I ran a test >> where it happened 11 out of 20 times. Today the highest occurrence has been >> 3 out of 40. >> >> To add some context here's some output from the test. Note both calls are >> identical but one gets a 400, the other 200: >> >>> curl -s -D- -u user:passwd -X POST --data @uc.json >>> https://ourdomain.com/ourapp/rest/v3/subscriber/<id>/user/0 2>&1 >>> >>> 21 : HTTP/1.1 400 Bad Request^M Date: Wed, 15 Oct 2014 18:44:22 GMT^M >>> X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1^M Content-Type: >>> application/json^M Content-Length: 361^M Connection: close^M ^M^M { >>> "ErrorMessage" : { "errorMessage" : "Json validation failure: >>> {level=\"error\", >>> schema={\"loadingURI\":\"#\",\"pointer\":\"/properties/userConfig/properties/userType\"}, >>> instance={\"pointer\":\"/userConfig/userType\"}, domain=\"validation\", >>> keyword=\"enum\", message=\"instance does not match any enum value\", >>> enum=[\"0\",\"1\",\"3\"], value=0}" } } >>> >>> curl -s -D- -u user:passwd -X POST --data @uc.json >>> https://ourdomain.com/ourapp/rest/v3/subscriber/<id>/user/0 2>&1 >>> >>> 22 : HTTP/1.1 200 OK^M Date: Wed, 15 Oct 2014 18:44:24 GMT^M >>> Transfer-Encoding: chunked^M Content-Type: text/plain; charset=UTF-8^M ^M { >>> "ErrorMessage" : { "errorMessage" : "Json validation failure: >>> {level=\"error\", >>> schema={\"loadingURI\":\"#\",\"pointer\":\"/properties/userConfig/properties/userType\"}, >>> instance={\"pointer\":\"/userConfig/userType\"}, domain=\"validation\", >>> keyword=\"enum\", message=\"instance does not match any enum value\", >>> enum=[\"0\",\"1\",\"3\"], value=0}" } } >>> >>> The following are the Apache ssl_access.log entries that correspond to >> the above calls. Note both got a 400: >> >>> 10.102.211.152 - - [15/Oct/2014:14:44:22 -0400] "POST >>> /ourapp/rest/v3/subscriber/<id>/user/0 HTTP/1.1" 400 361 >>> >>> 10.102.211.152 - - [15/Oct/2014:14:44:24 -0400] "POST >>> /ourapp/rest/v3/subscriber/<id>/user/0 HTTP/1.1" 400 361 >>> >>> More context: >> >> >> - This never happens going directly against the jboss server >> - It does happen both with and without SSL when hitting Apache >> - The tests results shown above were run with using curl as a client >> but we have also seen it happen with other clients(Charles, wireshark, IOS >> apps, etc) >> - Note that the 200 response above does not mention the jboss server >> but that the 400 does. I have verified that both requests hit the jboss >> server by locating the stack traces in the jboss log. >> - Normally there is an F5 in the mix and when hitting the app through >> it we get the same results. That said the tests referred to here >> bypassed the F5 and hit the Apache server directly >> >> So we should get a 400 but when it gets to the client the response code >> is 200. Any thoughts? >> > > Maybe some component encountered a problem which caused it to set status > to 400 AFTER httpd had already built the response header with 200 and > passed it down towards the network. > > Is anything in the error log? If not, do you have an available tracing > mechanism that shows function return values? Often an HTTP status code > will be the return value of a function at some point. (I have a module for > 2.4 that tells you the hook and the module that returned an error -- if it > was returned across a module interface -- but it is not fun to activate > since it requires rebuilding httpd. See > http://emptyhammock.blogspot.com/2014/05/which-apache-httpd-module-failed-request.html > ) > > >> -- >> Thanks, >> Tom Purcell >> Cell: 215-779-1963 >> >> > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > > -- Thanks, Tom Purcell Cell: 215-779-1963
