https://issues.apache.org/bugzilla/show_bug.cgi?id=56162
Sebb <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #5 from Sebb <[email protected]> --- (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? > > > > 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. > > > > 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. -- You are receiving this mail because: You are the assignee for the bug.
