-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vary header cache #298
Vary header cache #298
Conversation
…mode. We are not not doing any real work here and it simplifies our code.
This should make the code a bit more readable.
Extract the various methods for calculation of the expiration date into smaller methods in an attempt to make code more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all - thanks for this initiative. Also I appreciate the refactorings made, project needs them a lot.
One thing that I see is not sufficient is lack of multi-header handling for Vary. RFC allows that and I saw real servers working like that (https://tools.ietf.org/html/rfc7231#section-7.1.4).
IMO implementation has to use all of headers listed in Vary as part of cache entry key.
And yes, we need unit tests to see how it all will behave as integral.
@@ -152,22 +197,18 @@ private boolean hasVaryHeader(URLConnection conn) { | |||
* result to decide if result is cacheable | |||
*/ | |||
public void saveDetails(HttpResponse method, HTTPSampleResult res) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method contents looks like duplicate of another saveDetails
. I'd suggest refactoring common code into separate method to avoid duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is old code and a result of the different implementations of the http samplers. What refactoring do you have in mind?
@@ -626,6 +627,19 @@ protected HTTPSampleResult sample(URL url, String method, boolean areFollowingRe | |||
} | |||
} | |||
|
|||
private Header[] getHeaders(HeaderManager headerManager) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd make this protected
for extensibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of extracting it into a utility class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure on the functional side of the feature, however there is a couple of performance-wise issues.
return null; | ||
} | ||
for (String headerLine: reqHeaders.split("\n")) { | ||
if (headerLine.startsWith(headerName + ": ")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please move string concatenation out of a loop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking of splitting the headerLine
, so that I can easier compare the headerName
ignoring the case.
And as undera pointed out, a vary header can have multiple values (separated by comma), so this logic will have to be changed anyway.
if (varyHeader != null) { | ||
log.debug("Set entry into cache for url {} and vary {} ({})", url, | ||
varyHeader, | ||
varyUrl(url, varyHeader.getLeft(), varyHeader.getRight())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add isDebugEnabled
check to prevent varyUrl
computation in debug disabled case.
This depends on HashMap#toString to give consistent results, which is probably not true.
Thanks Felix for PR. Thanks |
Great progress, Felix! |
I think this feature can be tested now. |
Great @FSchumacher ! |
Hi Felix, I'd just change a bit in HTTPJavaImpl#getHeaders(HeaderManager headerManager) to: |
Hi Felix, Thanks |
In preparation of Bugzilla Id: 61176 (and github pr #298) git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1801854 13f79535-47bb-0310-9956-ffa450edef68
This should make the code a bit more readable. In preparation of Bugzilla Id: 61176 (and github pr #298) git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1801855 13f79535-47bb-0310-9956-ffa450edef68
Extract the various methods for calculation of the expiration date into smaller methods in an attempt to make code more readable. In preparation of Bugzilla Id: 61176 (and github pr #298) git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1801856 13f79535-47bb-0310-9956-ffa450edef68
In preparation of Bugzilla Id: 61176 (and github pr #298) git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1801857 13f79535-47bb-0310-9956-ffa450edef68
In preparation of Bugzilla Id: 61176 (and github pr #298) git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1801858 13f79535-47bb-0310-9956-ffa450edef68
First try on an implementation to support vary header as asked for in
https://bz.apache.org/bugzilla/show_bug.cgi?id=61176
Do not merge.
I haven't written tests yet, as I am not sure, if the code is going in the right direction.
The idea at the moment is to store two entries in the cache, when a vary header is found in the response headers. One entry for the original url with the name of the vary header set and one entry for the url+var-header-name+vary-header-value (of the request).
The code makes it clearer, that the two http samplers with slightly different implementation details make it harder to implement this. For example both samplers have different notions of how the headers are implemented.