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.
Related
I'm pulling my hairs for days trying to serve brotli compressed files through my local nginx install.
My configuration :
MacOS 12.6, Homebrew, Laravel Valet for managing sites and ssl
default nginx install replaced with nginx-full homebrew formulae that allows recompiling nginx with modules -> installed with the brotli module
I have tried different nginx brotli configuration, like this one
I think I do not have to do this, but I still tried to add specific proxy configurations for the files I want served with brotli
location ~ [^/]\.data\.br(/|$) {
add_header Content-Encoding br;
default_type application/octet-stream;
}
location ~ [^/]\.js\.br(/|$) {
add_header Content-Encoding br;
default_type application/javascript;
}
In the end, the http response does not contain content-encoding:br
nginx shows the module is installed :
$ nginx -V 2>&1 | tr ' ' '\n' | egrep -i 'brotli'
--add-module=/usr/local/share/brotli-nginx-module
When testing with curl it works for gzip but not for brotli :
HTTP/2 200
server: nginx/1.23.1
date: Thu, 20 Oct 2022 09:57:20 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
x-powered-by: PHP/8.1.10
access-control-allow-origin: *
content-encoding: gzip
HTTP/2 200
server: nginx/1.23.1
date: Thu, 20 Oct 2022 09:57:21 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
x-powered-by: PHP/8.1.10
access-control-allow-origin: *
HERE IT SHOULD BE "content-encoding: br" BUT IT'S NOT
Any idea is welcome, I don't understand what is going on... cheers.
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.
Why does Tomcat version 7.0.88 gives "400 Bad Request" error code if the hostname ends with xyx.com-abc.
For testing purpose let's assume we have the following entry in the hosts file
127.0.0.1 hello.hello.hello-erq
And we try to access this url from curl
curl -v hello.hello.hello-er:8080
We get the following output
* Rebuilt URL to: hello.hello.hello-er:8080/
* Trying 127.0.0.1...
* Connected to hello.hello.hello-er (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: hello.hello.hello-er:8080
> User-Agent: curl/7.49.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: Apache-Coyote/1.1
< Transfer-Encoding: chunked
< Date: Thu, 20 Dec 2018 19:53:09 GMT
< Connection: close
<
* Closing connection 0
While using the localhost in the url we get
C:\playground\apache-tomcat-7.0.88-windows-x64\apache-tomcat-7.0.88\bin>curl -v localhost:8080
* Rebuilt URL to: localhost:8080/
* Trying ::1...
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/html;charset=ISO-8859-1
< Transfer-Encoding: chunked
< Date: Thu, 20 Dec 2018 20:00:07 GMT
<
<!DOCTYPE html>
All the tomcat configurations are the same for both the tests and the same issue is replicated on a vanilla out of the box tomcat server too.
I tried to replicate the same issue on tomcat-8 but both the url's worked fine there. How can i dig deeper and find out the root cause of this issue in 7.0.88 ?
Is there some additional logging which i can enable to get more on this issue ?
Or the only thing i have left is to pull my hairs and upgrade ?
Tomcat was attempting to enforce the domain name specification by refusing your hostname with a hyphen in the TLD. This was deemed a bug in Tomcat and fixed in 7.0.89 (and versions of Tomcat 8.0.x, 8.5.x and 9.0.x released around the same time).
So it seems that all you need is a small version bump.
Follow instruction on this page:
https://support.sonatype.com/entries/22189106-How-can-I-programatically-upload-an-artifact-into-Nexus-
I was able to upload artifact to repository Australia by using this command:
curl -v -u admin:admin123 --upload-file RE_0.0.0.19.tar.gz http://nexus1.ccorp.com/nexus/content/repositories/Australia/RE_0.0.0.19.tar.gz
That doesn't create POM file or has artifactId associate with, which mean I won't able to query for latest build in that repository.
I then tried this command:
curl -v -F r=releases -F hasPom=false -F e=tar.gz -F g=Australia -F a=RE -F v=0.0.0.19 -F p=tar.gz -F file=RE_0.0.0_19.tar.gz -u admin:admin123 http://nexus1.ccorp.com/nexus/service/local/artifact/maven/content
I got this log with no error, but artifact is not uploaded:
Hostname was NOT found in DNS cache
Trying 10.10.5.92...
Connected to nexus1.ccorp.com (10.10.5.92) port 80 (#0)
Server auth using Basic with user 'admin'
POST /nexus/service/local/artifact/maven/content HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4xMjM=
User-Agent: curl/7.35.0
Host: nexus1.ccorp.com
Accept: /
Content-Length: 852
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------929d6986ddb3024d
HTTP/1.1 100 Continue
HTTP/1.1 201 Created
Date: Tue, 20 Oct 2015 20:29:11 GMT
Server Nexus/2.11.4-01 Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V8 is not blacklisted
Server: Nexus/2.11.4-01 Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V8
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=UTF-8
Content-Length: 85
Connection #0 to host nexus1.ccorp.com left intact
{"groupId":"Australia","artifactId":"RE","version":"0.0.0.19","packaging":"tar.gz"}
I have a problem with HttpFS service of hadoop.When i try to curl some resource:
curl -i http://192.168.4.180:14000/webhdfs/v1/user/hadoop/?op=LISTSTATUS
the response i get is:
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Mon, 17 Aug 2015 08:57:47 GMT
But when i try to do the same with webhdfs it works:
curl -i http://192.168.4.180:50070/webhdfs/v1/user/hadoop/?op=LISTSTATUS
HTTP/1.1 200 OK
and so on ....
Httpfs service is running on port 14000, i have checked it via nmap.
Any suggestions or ideas what might be the problem?
I meet the same problem. And solved by this link
In brief, you need to add the symbol link:
# Point to the 'webapps' in current.
cd /etc/hadoop-httpfs/tomcat-deployment
ln -s /usr/hdp/current/hadoop-httpfs/webapps webapps