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"}
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 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.
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.
I'm trying to configure the Vaadin addons repository in Artifactory, but I always get this error message:
When I change the url to just http://maven.vaadin.com, the connection test succeeds, but the artifacts cannot be resolved. I have other remote repositories configured that work.
Currently I have to resort to downloading and deploying the jar files manually.
Any ideas about what I could be doing wrong here?
Edit: Specific addon example (although all have failed for me, so far):
<dependency>
<groupId>org.vaadin.addons</groupId>
<artifactId>loginform</artifactId>
<version>0.5.2</version>
</dependency>
The test is failing since the Vaadin addons Maven repository does not support directory listing (browsing).
When Artifactory send a test request to the root of the repository it gets a 404 status:
$ curl -vv http://maven.vaadin.com/vaadin-addons/
* Trying 54.86.23.48...
* Connected to maven.vaadin.com (54.86.23.48) port 80 (#0)
> GET /vaadin-addons/ HTTP/1.1
> Host: maven.vaadin.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Thu, 17 Sep 2015 12:50:53 GMT
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< x-amz-request-id: 2F7E32DADE9E2C20
< x-amz-id-2: EjRvUE7kv4GOdPE0ry+VsmXvmva4QgBptK/CcnSESZbe2AqotmXpAuM3AuChq2Gd
<
<?xml version="1.0" encoding="UTF-8"?>
* Connection #0 to host maven.vaadin.com left intact
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>vaadin-addons/</Key><RequestId>2F7E32DADE9E2C20</RequestId><HostId>EjRvUE7kv4GOdPE0ry+VsmXvmva4QgBptK/CcnSESZbe2AqotmXpAuM3AuChq2Gd</HostId></Error>
However you can still use Artifactory to proxy this repository. You will be able to download artifacts from it.
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