Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
perf(pdk): refine with optional cache to improvement performance #13981
base: master
Are you sure you want to change the base?
perf(pdk): refine with optional cache to improvement performance #13981
Changes from 15 commits
c4aebf1
e5626cd
7c9ea30
ca17150
e0dc602
78cb953
e46dffb
ec8abf2
9c7520a
f4ce86a
bcdc538
40f7218
71e2a62
d5c781b
a64667b
f140e01
16b159c
b40a178
d21ef10
edd040a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
http_get_header
supportsctx
param to cache headers, expose it toget_header
API so we could use cache.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 don't like this either. If we add this parameter, we need to always keep the API like that, that the second parameter needs to be
ctx
. The benefits are so small that I would rather not do it. The most of the changes in plugins seems to be utilizing this. And that is also I think somewhat "bad" code to make people create tables of ctx and pass it here. If we cannot find better way to do this, then I would not do it.Just an example e.g. if someone wants to add more beneficial parameter lilke
default
in case the header is missing the code would become:Perhaps we will never add that either, but just tells that we don't want these strange
ctx
parameters in public API.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.
What if we use
kong.tools.get_header(name, ctx)
directly in plugins, to replace non-cachedkong.request.get_header
API in certain places to achieve the cache benefit? It must be better to use PDK APIs in plugins, but I do see that there are a lot ofkong.tools
usage in plugins(which I feel more like should be used "internally" in core or some non-plugin module?), Do you think it's a proper practice?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.
@ProBrian In general it would be best if we can get to state where there is no
require "module"
statements in plugins. That is we have a powerful PDK. But meanwhile, yes, many plugins require different modules. That also then spreads to all custom plugins as plugins are copy pasted. That then will make all our internal APIs and tools public too which we cannot break. I think for example those plugins, just call get_headers once and work with headers and call it done, rather than pass a table to somewhere that something else caches the get_headers.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.
@ProBrian
ngx.var.content_type
does not seem to be single header. If you send multiple, you will get"<value1>, <value2>, ..."
.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.
What is even more annoying is that:
is only reflected with the first value. Seems like
clear_header
is needed together withset_header
?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 seems to work properly:
If I don't do
clear_header
, it does not work properly.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 the request I am using:
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.
Seems there's a mismatch limitation between openresty and nginx that I've ignored, that is,
nginx allows multiple line values for headers like "Content-Type".
And openresty defines a list of headers that is "built-in single value", which includes
"Content-Type"
.ngx.req.set_header
will not allow multiple value for"Content-Type"
, so if wengx.req.set_header("Content-Type", {"json1", "json2"})
, it will use the last elem as the single value, so thenngx.req.get_headers()["Content-Type"]
andngx.var.http_content_type
will all get a single value"json2"
.But when multiple content type header is sent by http request client, not by openresty set_header API, then the header value is just handled by nginx, and
get_headers
will get a table{"json1", "json2"}
andngx.var.http_content_type
will get the value as comma separated string:"json1, json2"
.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.
That's due to the implementation of openresty, it assumes that
Content-Type
should be single value, so in set_header implementation, the assignment will only take place in the first index of value list.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 will rollback the
var.http_content_type
changes, sincekong.request.get_header
will only get the first value no mattercontent-type
is multi value or not from downstream; butvar.http_content_type
rely on the assumption that downstream send singlecontent-type
orcontent-type
is set byngx.req.set_header
.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.
Should we keep the original code here?
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.
ngx.header
is the better way to get a single response header, and it returns the same type of values asget_headers()[name]
: ifget_headers()[name]
get a table,ngx.header
will get a table similarly(unlikengx.var.sent_http_
which returns comma separated string). So we make this change for better performance.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 a minor refinement so that if we could reduce the reads of
ngx.ctx.buffered_proxying
by passing it by paramThere 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.
Use a local
ctx
here which is cheaper thanngx.ctx
, and the cache is only fresh in the localctx
lifetime, not in the request lifetime, so we don't needngx.ctx