How to handle status 304 in repeat loop

[imeh...@gmail.com]

---- Response Time Distribution ------------------------------------------------

> t < 250 ms                                             0 (  0%)

> 250 ms < t < 750 ms                                   12 ( 52%)

> t > 750 ms                                             2 (  9%)

> failed                                                 9 ( 39%)

---- Errors --------------------------------------------------------------------

> status.find.is(200), but actually found 304                         9 (100.0%)

================================================================================

I am running a GET on a same resource in a repeat loop. First request passes with 200 OK and then subsequently it responds with 304. How can I make sure it's 200 everytime ? I think I am looking for something that will clear the cache, but if this is known issue can someone help me. Thank you.

repeat(10) {
  exec(ExecutionHelpers.getExecution("Service", "${servicesPath}/${key}"))
}

[Barry Perez]

Hi,

What do your clients do?

Take a look at the documentation around the 304 response code - https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

And this page might be useful... what request and response headers are involved in the interaction? https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests

Cheers,

Barry

[imeh...@gmail.com]

I can follow the note given here: 

A status check is automatically added to a request when you don’t specify one. It checks that the HTTP response has a 2XX or 304 status code.

I think it's good if I comment out the line ".check(status.is(200)" since by default it checks for 2XX and 304 assuming 304 is a server side response when body is not modified. Any suggestion or opinion? I appreciate for the links, I always miss mozilla docs, they are so good.

[Barry Perez]

I'd more be looking to see if the 304 is the response a real client would actually be expecting; it normally means that a client has received that particular information previously and the data hasn't changed (it's probably driven by the request headers you're adding, which is why I asked about these).

This could be expected if one client is making repeated requests but would not be realistic if the requests come from many different clients - and if you are getting 304 with no response body as opposed to 200 with a body, there are different implications on processing at the server side, as well as network transfer requirements.

Barry

[vishal singh]

Did you get the solution to avoid 304 from Gatling?

On Thursday, July 27, 2017 at 1:00:17 AM UTC+5:30, imeh...@gmail.com wrote: