-
Notifications
You must be signed in to change notification settings - Fork 780
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
Implement Cache-Control: immutable handling #1516
Conversation
Linux build failed! See https://ci.trafficserver.apache.org/job/linux-github/1541/ for details. |
I'm on the fence about including the |
FreeBSD build successful! See https://ci.trafficserver.apache.org/job/freebsd-github/1647/ for details. |
Intel CC build successful! See https://ci.trafficserver.apache.org/job/icc-github/79/ for details. |
Linux build successful! See https://ci.trafficserver.apache.org/job/linux-github/1543/ for details. |
I would like to do the review on this. |
FreeBSD build successful! See https://ci.trafficserver.apache.org/job/freebsd-github/1649/ for details. |
Intel CC build successful! See https://ci.trafficserver.apache.org/job/icc-github/81/ for details. |
Linux build successful! See https://ci.trafficserver.apache.org/job/linux-github/1546/ for details. |
clang-analyzer build successful! See https://ci.trafficserver.apache.org/job/clang-analyzer-github/211/ for details. |
clang-analyzer build successful! See https://ci.trafficserver.apache.org/job/clang-analyzer-github/213/ for details. |
plugins/esi/combo_handler.cc
Outdated
string generate() const; | ||
|
||
// Cache-Control values we're keeping track of | ||
int _max_age = 315360000; // max value (10 years) |
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.
probably should be unsigned?
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.
Or ssize_t
. Is the 10 year value from the HTTP spec?
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.
Actually I believe the max value should be 1 year. According to RFC 2616,
To mark a response as "never expires," an origin server sends an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.
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'll remove a 0 from the constant if everyone agrees.
plugins/esi/combo_handler.cc
Outdated
// Cache-Control values we're keeping track of | ||
int _max_age = 315360000; // max value (10 years) | ||
bool _public = true; | ||
bool _private = false; |
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 find it rather confusing to maintain two booleans here - _public and _private.
Is there any other kind of value?
If not, perhaps we can simply this to be just one boolean?
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.
Hmmm, perhaps a tri-value enum? private
, public
, default
?
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.
Yeah the tri-enum sounds better. I knew that public & private were disjoint, but there was the default case I wanted to handle too.
I am not in favor with the "private" related changes because i think it can catch some existing users by surprise. And we did not mention anything in the document as well - https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/combo_handler.en.html Speaking of the document, it would be great if we can update that, too. Thanks. |
The max-age related code is also a bit different from before. Previously we can have max-age larger than 315360000. Now with this change, I think we can no longer have max-age larger than that. right? |
plugins/esi/combo_handler.cc
Outdated
TSHandleMLocRelease(bufp, hdr_loc, field_loc); | ||
return; | ||
} | ||
TSHandleMLocRelease(bufp, hdr_loc, field_loc); |
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 piece seems a bit redundant? from line 232 to 236, i mean
will try to compile it tonight and see if i have more comments. |
plugins/esi/combo_handler.cc
Outdated
} | ||
immutable = (_immutable ? ", " HTTP_IMMUTABLE : ""); | ||
|
||
sprintf(line_buf, "Cache-Control: max-age=%d, %s%s\r\n", _max_age, publicity, immutable); |
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.
if we happen to support and have a case of having a really large (!) number for max age, we might have buffer overflow.
Then we might need to consider snprintf or something safer?
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.
The longest possible value is -(2^64) which has some finite number of digits. That should be computable and line_buf
adjusted to suffice in that case.
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.
2^64 ~ 1.84x10^{19}, so it won't be over 20 digits long. The buffer is 256 chars wide so I think we're good.
the patch compiles fine. And it seems to run through clang-format as well already. thanks. pls check out the comments above. |
plugins/esi/combo_handler.cc
Outdated
string generate() const; | ||
|
||
// Cache-Control values we're keeping track of | ||
int _max_age = 315360000; // max value (10 years) |
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.
Or ssize_t
. Is the 10 year value from the HTTP spec?
plugins/esi/combo_handler.cc
Outdated
void | ||
CacheControlHeader::update(TSMBuffer bufp, TSMLoc hdr_loc) | ||
{ | ||
vector<string> values; |
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.
Perhaps convolute the search logic. In that case there would be a std::array<char const*, 3>
initialized to the 3 values of interest. Each item in the loop at 221 would have an inner loop like that starting at 241. Then there's no need to allocate a vector as a temporary, and the comparisons can be done using strcasecmp
to avoid the copy as well.
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 would also simplify the logic Kit was concerned about at 232-236.
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.
Why a loop? If we use a loop then it's harder to set the found_private
and found_immutable
flags. I feel like unrolling the loop in this case is better since the # of parameters in Cache-Control is known.
I agree with the private/public refactor. The code would be significantly uglier if processing for the cache control field was split. |
FreeBSD build successful! See https://ci.trafficserver.apache.org/job/freebsd-github/1685/ for details. |
Intel CC build successful! See https://ci.trafficserver.apache.org/job/icc-github/117/ for details. |
Linux build successful! See https://ci.trafficserver.apache.org/job/linux-github/1581/ for details. |
clang-analyzer build successful! See https://ci.trafficserver.apache.org/job/clang-analyzer-github/249/ for details. |
clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/331/ |
clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/332/ |
looks good. thanks. @SolidWallOfCode , any other comments you have? |
I didn't realize there was a doc page for that. Updating now. |
I just copied over the same text from the README to the admin config docs. |
clang format successful! https://ci.trafficserver.apache.org/job/clang-format-github/76/ |
RAT check successful! https://ci.trafficserver.apache.org/job/RAT-github/89/ |
AU check successful! https://ci.trafficserver.apache.org/job/autest-github/73/ |
FreeBSD11 build successful! https://ci.trafficserver.apache.org/job/freebsd-github/1771/ |
Linux build successful! https://ci.trafficserver.apache.org/job/linux-github/1664/ |
Intel CC build successful! https://ci.trafficserver.apache.org/job/icc-github/202/ |
clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/334/ |
======= | ||
Combohandler follows a few rules for the "Cache-Control" header: | ||
|
||
1) All requested documents must have "immutable" for the combo'd |
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.
just nitpicking. I think for markdown, the syntax of "ordered list" is just "1. "
right?
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.
Not that I knew this beforehand, but this is restructured text and it looks like this is the correct list syntax. Got lucky I guess.
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.
yeah, you are right.
can you squash now? then i can verify and merge. |
Before, combohandler would not insert the immutable cache control even if all the requested documents had the header. Now, combohandler will respect the presence of the header.
0dff5de
to
a73e93a
Compare
done |
clang format successful! https://ci.trafficserver.apache.org/job/clang-format-github/80/ |
RAT check successful! https://ci.trafficserver.apache.org/job/RAT-github/93/ |
AU check successful! https://ci.trafficserver.apache.org/job/autest-github/77/ |
FreeBSD11 build successful! https://ci.trafficserver.apache.org/job/freebsd-github/1775/ |
Linux build successful! https://ci.trafficserver.apache.org/job/linux-github/1668/ |
Intel CC build successful! https://ci.trafficserver.apache.org/job/icc-github/206/ |
clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/338/ |
This patch makes
combo_handler
correctly handle the presence of one or moreCache-Control: immutable
flags.In short, the combo response will be immutable if and only if all requested documents have immutable in their response headers.
In addition, the same logic applies for
Cache-Control: private
. This was not present before.