https://issues.apache.org/bugzilla/show_bug.cgi?id=56162

--- Comment #6 from Matt Parker <[email protected]> ---
(In reply to Sebb from comment #5)
> (In reply to Matt Parker from comment #4)
> > (In reply to Sebb from comment #2)
> > > Not sure I understand the use case.
> > > 
> > > Surely if the PUT changes the target of the GET, the Etag should change?
> > 
> > You're correct, the ETag value does change, and the CacheManager works
> > properly with respect to this. However, I then want to create a new GET
> > request specifically to retrieve the full entity, but I no longer have the
> > ability to do this once the CacheManager is there.
> 
> That's the part I don't understand.
> Surely the next GET after the PUT won't return the cached entry?
> If it does, then perhaps CM - or the site - is faulty?

Technically, both CM and the site are working properly. But CM's behavior is
too restrictive to allow me to do what I want. After the PUT, the 2xx response
from the site includes the updated ETag value. CM sees that ETag value in the
PUT response, caches it, and inserts it on the next GET. From the site's
perspective, the client has provided the correct cache validator, and so
returns 304. What I'm trying to do is to override the etag value that CM
inserts, so that I can get back a 200 instead of a 304.

> 
> > > 
> > > How does the JMeter behaviour differ from that of a browser?
> > > [Apart from the fact that JMeter does not store the page contents, so 
> > > cached
> > > gets are empty]
> > 
> > JMeter allows me to arbitrarily change headers and their values with each
> > request,  whereas a browser does not. This makes JMeter a much better tool
> > for testing HTTP APIs than a web browser.
> 
> Yes, though of course the site must still work when used by a browser.

Agreed.

> 
> > > 
> > > It would be helpful to have details of the request response headers sent 
> > > by
> > > JMeter and also by a browser.
> > 
> > I'm sure they would look identical, but this is more about the decreased
> > ability to change the header values in a test, than it is about how it
> > mimics a web browser.
> 
> That's a bit different.
> 
> As far as I understand your use case, it should not need you to override
> headers. If it does require this currently, then we need to establish why
> that is. Better to fix JMeter (if it is wrong) than to have to use a
> work-round.

The attached test case illustrates the problem, and I'll outline my real-world
test.

Attached test case:
0. A CacheManager is added to the test plan
1. sampler performs a GET http://www.mnot.net/cache_docs/
2. the site responds with 200 OK, and an ETag value (amongst other header
values)
3. CM recognizes the ETag value and copies it
4. sampler performs another GET request for the same item
5. CM intelligently inserts the etag value into the if-none-match header
6. the etag value matches what the site has, so the site returns 304
7. I want to force a 200 response, rather than a 304, so I add an if-none-match
header (guaranteed to not match) to the next sampler
8. CM overrides the if-none-match value I provided, and uses its value. (This
is the behavior I'd like to control)

In my real-world test, I am testing a RESTful API--I am doing a POST, followed
by a GET to validate that the body matches what I previously created. Then I am
validating that the server API processes the conditional GET properly, by using
the CM and another GET. Then I perform a PUT, changing the contents (the server
responds with a 204 and an ETag). Lastly, I want to validate that the server
sends back the exact contents that I PUT (I want a 200), but since CM is
automatically working its magic, I can't get anything back but a 304 No
Content.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to