Status code 200 didn’t match expected: 304
Suppose you’ve got a testcase that either worked in the past, or just works sometimes, but now seems to be giving you an error: “The status code of the response (200) did not match the status code of the response in the Testcase (304)”. This particular error message is probably not a serious error, but it usually means that your test isn’t quite emulating what a real browser would do.
Fixing this problem in Load Tester is usually easy. Just right click on your testcase, select Properties, and then go to the “Restart Options” tab. Simply check the last checkbox: “Update If-Modified-Since/If-None-Match headers dynamically”, and press OK.
To understand this problem, let’s first take a look at the error message. “did not match the status code of the response in the Testcase (304)” means Load Tester was expecting a 304, based on the original recording. A HTTP 304 means “Not Modified”, and is used whenever the browser is simply checking a file against a cached value. This means the browser already has the file, and is comparing the Last Modified, and/or the ETag identifying the resource. This means that by looking backwards in the testcase, there is a good chance you’ll find the same transaction requested earlier, but where a 200 response was received, or the recording was made without having the browser’s cache automatically cleared.
In the case where a 200 was received earlier, this response will contain the Last Modified header and/or the ETag header which the browser will use later to check for a change in the file. By turning on the “Update If-Modified-Since/If-None-Match headers dynamically” feature, Load Tester will automatically use the received headers from the 200 response to replace the request headers when it expects a 304.
Without this feature turned on, there are two likely causes this failure appears:
- The resource has changed since the last time the testcase was recorded
- The server has changed from the one on which the testcase was recorded. In Load Balanced environments, this can mean that the Load Balancer has selected a different server for the user than it did during recording, which usually means that this error only appears occasionally.
The Load Balanced environment also leads to another scenario – that this isn’t a testcase configuration issue at all. For environments which do not use sticky sessions, or are not performing session assignment for the resource in question, this can mean that for any browser performing a cache check, the full content of the file may be sent, even if the file hasn’t changed. In this scenario, your site is consuming bandwidth than would otherwise be required. If so, try to synchronize Last-Modified and ETag headers between your webservers. If and only if you are still willing to accept that behavior, you can remove the status code validator (on the Actors View) to turn off the error messages and move on with your test.
-Frank, Engineer at Web Performance, Inc.