We are currently using the file-log plugin to write a text file for all requests. For a recently-added API entry, the “request” section of the log entry did not have an Authorization header listed, but had many other normal headers. The response from the upstream URL was a 303 redirect to a login page, which would be the generic response for requests without an Authorization header.
The support team for the application generating the request has stated that they are sending the Authorization header. Since that specific header is not appearing in the logfile on requests from that application, my questions are:
Is there a known behavior of the file-log plugin that would exclude an Authorization header (or any other header) from the ‘request’ section of the logfile based on the response, such as the 303 we are receiving in this case?
More generally, can I be assured that the ‘request’ section of the out put of file-log will list all headers that were received by Kong on the request? I realize that a proxy placed before Kong might do filtering of headers, but if that is not the case, then is it true that 'what I see in the logfile is what Kong got"?
So no, the file-log plugin doesn’t “hide” any headers (from the request or the response).
However, note that I said at that moment. The logging occurs in the log phase, one of the latest phases when treating a request. If you have other plugins installed, they might be altering the headers prior to this phase.
If you have no other plugins installed and there are no other network elements which can modify the traffic between upstream and kong, then yes. Otherwise, you would have to check those plugins & network elements to be sure.
Thank you for the response. In this particular example, there aren’t any plugins associated to the API that modify the request, so we should be good there.
I am intrigued by the mention of ‘network elements which can modify the traffic between upstream and kong’. When you reference an ‘upstream’, do you mean the application making the request (which makes sense as Kong hasn’t gotten the request yet), or do you mean the API designated in the upstream_url configuration?
When you reference an ‘upstream’, do you mean the application making the request (which makes sense as Kong hasn’t gotten the request yet), or do you mean the API designated in the upstream_url configuration?
Apologies, in your case I should have written “between downstream and Kong”.
The application making the request is what we call “downstream”. The API serving the request is “upstream”. In other words, a request is processed like this:
A request comes from downstream to Kong.
Kong processes the request and then sends it to the upstream server it decides (according to service/route rules as well as other things like healthchecks or custom plugins).
The upstream API receives the request from Kong and produces a response, which it sends back to Kong
Kong further processes the response, and then sends it back downstream.
If downstream is producing a header, but it doesn’t reach kong, it could be that there is a third element in the network between downstream and kong (like a firewall) doing the filtering.
Perfect, thank you so much. The process you describe is as I understood it to be, with the addition that I need to remember file-log happens after other plugins that may affect a request.