I have a registered service in Kong and currently trying to set up the proxy-cache plugin.
The plugin itself works fine when cache control is set to false, but when I enable it, the X-Cache-Status header is always Bypass.
The plugin configuration looks like this:
plugins:
- name: proxy-cache
service: echo
config:
response_code
- 200
- 301
- 404
request_method:
- GET
- HEAD
content_type:
- text/plain
- application/json
- application/json; charset=utf-8
- text/plain; charset=utf-8
cache_ttl: 300
strategy: memory
cache_control: true
memory:
dictionary_name: kong_db_cache
And the request looks like this:
curl --location --request GET 'http://localhost:8000/echo' --header 'Cache-Control: public, max-age=20'
I was experimenting with different Cache-Control values, registered also request-transformer plugin and was playing with headers there, but nothing seems to work.
Did anyone encounter this issue before? I'm pretty much stuck here and any kind of suggestion is more than welcome.
You have set the option
cache_control: true
So Kong will respect the Cache-Control behaviors defined in RFC7234
You need to have an cache header into the upstream answer.
Or you should set it to false
Related
I am completely new to APISIX and I am following the getting-started tutorial.
The problem is in editing routes. More specifically, I create a route using this example of the tutorial and it works as expected. Next I am editing the route's uri using:
# Please notice the extra 'g' in the uri value 'anythingg' compared to the previous uri
curl "http://127.0.0.1:9080/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PATCH -d '
{
"uri": "/anythingg/*"
}'
Then I am trying to connect to the endpoint using the new and the old uri but I am getting an 404 in both cases with different messages! The requests-responses:
New uri
$ curl -i -X GET "http://127.0.0.1:9080/anythingg/foo?arg=10" -H "Host: example.com"
HTTP/1.1 404 NOT FOUND
Content-Type: text/html; charset=utf-8
Content-Length: 233
Connection: keep-alive
Date: Tue, 13 Sep 2022 09:13:40 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Server: APISIX/2.15.0
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.</p>
Old uri
$ curl -i -X GET "http://127.0.0.1:9080/anything/foo?arg=10" -H "Host: example.com"
HTTP/1.1 404 Not Found
Date: Tue, 13 Sep 2022 09:13:45 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/2.15.0
{"error_msg":"404 Route Not Found"}
How could I update the route rules and get the expected results and what is the cause of the observed behavior?
Thanks!
The error in the new URI indicates that it was returned by httpbin, not APISIX; in the old URI, it was returned by APISIX.
You can update the route in its entirety via the PUT method to ensure it is updated successfully.
I am using a consul client to deregister a service from my junit tests. I am using vert-consul-client . the consul version i am using is 1.11.1 . the service is not registered with the consul , but just testing what will happen if we try to deregister a service that is not registered.
from the logs i get this error
Status message: 'Not Found'. Body: 'Unknown service "BadService"'
strangely i dont get this error when testing with 1.10.6 consul version.
appreciate if you can help
thanks
strangely i dont get this error when testing with 1.10.6 consul version.
Consul recently changed the HTTP response code that is sent when an attempt is made to deregister a non-existent service.
Prior to Consul 1.11.0, and when ACLs were disabled, Consul would respond with a HTTP 200 response code and no response body when deregistering a non-existent service.
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 200 OK
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:07:35 GMT
Content-Length: 0
This behavior was changed in Consul 1.11.0 by PR hashicorp/consul#10632 wherein Consul now returns a HTTP 404 response code if a service does not exist, regardless of whether ACLs are enabled. (See diff of consul/agent/acl.go).
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 404 Not Found
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:24:21 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
You're obviously not seeing an error in vertx-consul-client when communicating to Consul 1.10.6 because the HTTP 200 code indicates that the request was successful, whereas the HTTP 404 response correctly signals that the resource does not exist, and an error is correctly raised (see vert-consul-client/src/main/java/io/vertx/ext/consul/impl/ConsulClientImpl.java#L1320-L1333).
Interestingly in Consul 1.10.x, when ACLs are enabled on the cluster, Consul would reply with a HTTP 500 error code and a corresponding error message instead of the 200 response code. This is because when ACLs are enabled, the vetServiceUpdateWithAuthorizer function does not prematurely return (if authz == nil { return nil }) and proceeds with checking whether service exists, then raising an error because it does not (see consul/agent/acl.go#L96-L104).
$ curl --include \
--header "X-Consul-Token: $CONSUL_HTTP_TOKEN" \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 500 Internal Server Error
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
Date: Wed, 05 Jan 2022 03:14:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
If you had tested 1.10.6 with ACLs enabled, you would've also received a similar error as you are seeing with 1.11.1.
I am using version 2.3.2 of elasticsearch. In my elasticsearch.yml file I have added the below lines to allow Cross-Origin requests.
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-methods: OPTIONS,HEAD,GET,POST,PUT,DELETE
http.cors.max-age: 0
http.cors.allow-origin: /http?:\/\/localhost(:[0-9]+)?/
http.cors.allow-headers : X-Requested-With,X-Auth-Token,Content-Type,Content-Length
However, when i try to execute a query from Firefox, I get the following error;
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://localhost:9200/someIndex/_search?size=10&from=0.
(Reason: CORS header 'Access-Control-Allow-Origin' missing).
Replacing the http.cors.allow-origin parameter with "*", seems to work, but the documentation indicates this is a security requests.
The request headers from the browser are below;
Accept - application/json, text/plain, */*
Accept-Encoding - gzip, deflate
Accept-Language - en-US,en;q=0.5
Content-Length - 26
Content-Type - application/json;charset=utf-8
DNT - 1
Host - localhost:9200
Origin - null
User-Agent - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Could someone please suggest what I am doing wrong in the above?
You seem to have a small typo.
It should read
http.cors.allow-origin: /https?:\/\/localhost(:[0-9]+)?/
^
|
add this
i.e. you're missing the s before the ?, which means "either http or https"
I seem to be having some problems with my Varnish set up. I have a clean install of Varnish and Nginx running on ubuntu, everything seems to be running, but I don't seem to be actually caching anything.
This is what im seeing:
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.9-1ubuntu4.14
Cache-Control: no-cache
Date: Tue, 02 Feb 2016 10:15:17 GMT
Content-Encoding: gzip
X-Varnish: 196655
Age: 0
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Connection: keep-alive
I'm almost certain the problem is to do with the "age" response being 0. I have read that the Cache-Control header can be the culprit and have spent some time configuring both nginx and my vcl file with solutions I have read on-line, none of which have worked.
I'm open to any ideas even ones I have tried before (hence why im not listing the steps I have already taken).
Thanks in advance for any thoughts you might have.
Remove "no-cache" and set "max-age=120" (in seconds) in the Cache-Control header instead.
Also note that if the request contains any cookies or if the response sets any cookies than by default varnish is not gonna cache.
I have 3 marathon servers running in HA. when i reach the rest api on the leader, it returns good data. But when i try it against one of the non leader nodes, I do not get any data back...no strings at all. The headers say 200...but no data. Has anybody experienced this before?
here is what i see on the leader
# curl -i http://10.0.0.1:8080/v2/apps
HTTP/1.1 200 OK
X-Marathon-Leader: http://x1-master-0:8080
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: application/json; qs=2
Connection: close
Server: Jetty(8.y.z-SNAPSHOT)
{"apps":[]}
here is the data from the non leader
# curl -i http://10.0.0.2:8080/v2/apps
HTTP/1.1 200 OK
Connection: close
Server: Jetty(8.y.z-SNAPSHOT)
the problem was that the marathon servers could not resolve each other by name. Adding the hostnames of the other marathon servers to each marathon's /etc/hosts file fixed the problem.