This bombs out:
$p = file_get_contents('https://graph.facebook.com/oauth/access_token');
With:
file_get_contents(https://graph.facebook.com/oauth/access_token): failed to open stream:
HTTP request failed! HTTP/1.1 400 Bad Request
Why?
I have OPENSSL enabled in Apache. I can see curl is on. What am I missing? I do have:
openssl: yes
http wrapper: yes
https wrapper: yes
wrappers: array(12) {
[0]=>
string(3) "php"
[1]=>
string(4) "file"
[2]=>
string(4) "glob"
[3]=>
string(4) "data"
[4]=>
string(4) "http"
[5]=>
string(3) "ftp"
[6]=>
string(3) "zip"
[7]=>
string(13) "compress.zlib"
[8]=>
string(14) "compress.bzip2"
[9]=>
string(5) "https"
[10]=>
string(4) "ftps"
[11]=>
string(4) "phar"
}
The problem turned out to be the settings in Facebook. I can access the HTTPs link, but Facebook returns a 400 error because I am not connecting from the right IP. facepalm
Related
I am currently working on a VSCode extension that internally makes some API calls to a HTTPS protected endpoint. On Linux and Mac OS the extension works as expected but on Windows machines axios, the internal HTTP client used to make the API calls, is rejecting those requests due to the certificates being expired. When I access the API endpoint though via Firefox, Chrome and even Edge the certificates seems find.
I have upgraded Node to 16.14.0 and also to 17.6.0 but the problem still remains. As the API is only accessible through our VPN, with my VPN activated of course, I used testssl.sh to verify that the whole trust-chain is still valid:
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered (OK)
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 h2, http/1.1 (offered)
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered
Obsolete CBC ciphers (AES, ARIA etc.) offered
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA
DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
DH group offered: HAProxy (2048 bits)
Testing server preferences
Has server cipher order? yes (OK) -- TLS 1.3 and below
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Cipher order
TLSv1.2: ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256
...
Certificate Validity (UTC) 65 >= 30 days (2022-02-01 08:18 --> 2022-05-02 08:18)
...
The other certificates in the trustchain are also valid and not expired at all.
Axios is used within an own HttpClient class that looks like this:
export class HttpClient {
private readonly instance: AxiosInstance;
constructor() {
this.instance = axios.create();
}
async asyncGet<T>(url: string): Promise<Response<T>> {
return this.instance.get<T>(url)
.then(axiosResponse => {
...
})
.catch(error => {
console.error(error);
throw error;
});
}
}
I also tried the https
const options: https:RequestOptions = {
hostname: '...',
port: 443,
path: '/...',
method: 'GET'
};
const request = https.request(url, options, (res: IncomingMessage) => {
console.log(`statusCode: ${res.statusCode ? res.statusCode : 'undefined'}`);
res.on('data', d => {
process.stdout.write(d as string);
}
});
request.on('error', error => {
console.error(error);
};
request.end();
analog to the samples given in the NodeJS documentation and tls
const socket = tls.connect(443, hostname, undefined, () => {
console.log('Connected to ' + hostname);
console.log('TLS.connect', socket.authorized ? 'authorized' : 'unauthorized');
console.log('Cipher: ' + JSON.stringify(socket.getCipher()));
console.log('Protocol: ' + JSON.stringify(socket.getProtocol()));
const peerCert: tls.DetailedPeerCertificate = socket.getPeerCertificate(true);
console.log(`Peer-Cert ${JSON.stringify(peerCert.subject)} - valid from: ${peerCert ? peerCert.valid_from : 'invalid'} valid till: ${peerCert ? peerCert.valid_to : 'invalid'}`);
const issuerCert = peerCert.issuerCertificate;
console.log(`issuer-Cert ${JSON.stringify(issuerCert.subject)} - valid from: ${issuerCert ? issuerCert.valid_from : 'invalid'} valid till: ${issuerCert ? issuerCert.valid_to : 'invalid'}`);
const rootCert = issuerCert.issuerCertificate;
console.log(`root-Cert ${JSON.stringify(rootCert.subject)} - valid from: ${rootCert ? rootCert.valid_from : 'invalid'} valid till: ${rootCert ? rootCert.valid_to : 'invalid'}`);
});
as proposed in this answer.
Both axios and https return an error like this:
{
"message": "certificate has expired",
"name": "Error",
"stack": "Error: certificate has expired\n\tat TLSSocket.onConnectSecure (_tls_wrap.js:1497:34)\n\tat TLSSocket.emit (events.js:315:20)\n\tat TLSSocket._finishInit (_tls_wrap.js:932:8)\n\tat TLSWrap.onhandshakedone (_tls_wrap.js:706:12)\n\tat TLSWrap.callbackTrampoline (internal/async_hooks.js:131:14)",
"config": {
"transitional": {
"silentJSONParsing": true,
"forcedJSONParsing": true,
"clarifyTimeoutError": false
},
"transformRequest": [
"null"
],
"transformResponse": [
"null"
],
"timeout": 0,
"xsrfCookieName": "XSRF-TOKEN",
"xsrfHeaderName": "X-XSRF-TOKEN",
"maxContentLength": -1,
"maxBodyLength": -1,
"headers": {
"Accept": "application/json, text/plain, */*",
"user-Agent": "axios/0.26.0"
},
"method": "get",
"url": "https://..."
},
"code": "CERT_HAS_EXPIRED",
"status": null
}
with a more human-readable stacktrace:
Error: certificate has expired
at TLSSocket.onConnectSecure (_tls_wrap.js:1497:34)
at TLSSocket.emit (events.js:315:20)
at TLSSocket._finishInit (_tls_wrap.js:932:8)
at TLSWrap.onhandshakedone (_tls_wrap.js:706:12)
at TLSWrap.callbackTrampoline (internal/async_hooks.js:131:14)
while for tls I get the following output:
Connected to ...
TLS.connect authorized
Cipher: {"name":"TLS_CHACHA20_POLY1305_SHA256","standardName":"TLS_CHACHA20_POLY1305_SHA256","version":"TLSv1/SSLv3"}
Protocol: "TLSv1.3"
Peer-Cert {"CN": "*...."} - valid from: Feb 1 08:18:23 2022 GMT valid till: May 2 08:18:22 2022 GMT
issuer-Cert {"C":"US","O":"Let's Encrypt","CN":"R3"} - valid from Sep 4 00:00:00 2020 GMT valid till: Sep 15 16:00:00 2025 GMT
root-Cert {"C":"US","O":"Internet Security Research Group","CN":"ISRG Root X1"} - valid from: Jan 20 19:14:03 2021 GMT valid till: Sep 30 18:14:03 2024 GMT
So tls seems to be able to connect to the API server and perform the SSL/TLS handshake, but https and axios somehow fail.
I also stumbled upon this question here, which seems to be related, but as I am already on the latest NodeJS release (as well as any dependency used in the extension is on the most recent version) and this error only occurs on Windows (mostly 10, unsure if and how many users actually use Windows 11) machines I think the question deserves its own spot here on SO.
In order to rule out a lack of common supported ciphers between the Windows and Node.js based tls implementation and the nginx managed server side, I also checked the available ciphers in Node via node -p crypto.constants.defaultCoreCipherList which returns a list like this:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA256
HIGH
!aNULL
!eNULL
!EXPORT
!DES
!RC4
!MD5
!PSK
!SRP
!CAMELLIA
which indicates that enough ciphers would overlap between client and server.
Why do I still get a certificate expired error on Windows machines with axios/https
when Linux and MacOS work just fine with these settings and tls is able to connect to the remote API sucessfully even on Windows machines?
I'm using logstash 6.5.4 in centos7 for collecting the information from system and sending it to node server through http output plugin. following is my code.
input {
stdin{}
}
output{
stdout{}
http {
url => "http://nodeserver.example.in:5000/send"
format => "json"
http_method => "post"
headers => ["Authorization", "Bearer ${CLOG_TOKEN}"]
content_type => "application/json"
}
}
with the stdout{} plugin I'm getting output on console,
but with http{} plugin I'm getting http output failure error
[2020-05-27T16:19:37,789][ERROR][logstash.outputs.http ] [HTTP Output Failure] Could not fetch URL {:url=>"http://nodeserver.example.in:5000/send", :method=>:post, :body=>"{\"#version\":\"1\",\"host\":\"vm2\",\"message\":\"hello\",\"#timestamp\":\"2020-05-27T10:49:32.699Z\"}", :headers=>{"Authorization"=>"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTMxNjgzODIsInVzZXJuYW1lIjoic3lzYWRtaW4iLCJvcmdOYW1lIjoiUHJvdmlkZXJPcmciLCJyb2xlIjoid3JpdGVyIiwiaWF0IjoxNTkwNTc2MzgyfQ.vNaPEBhxG26oUYNKBYHKFtE0FH8mqHsKJRd45UjWFZE", "Content-Type"=>"application/json"}, :message=>"Connection reset", :class=>"Manticore::SocketException", :backtrace=>["/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/manticore-0.6.4-java/lib/manticore/response.rb:37:in `block in initialize'", "/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/manticore-0.6.4-java/lib/manticore/response.rb:79:in `call'", "/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/logstash-output-http-5.2.3/lib/logstash/outputs/http.rb:239:in `send_event'", "/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/logstash-output-http-5.2.3/lib/logstash/outputs/http.rb:175:in `send_events'", "/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/logstash-output-http-5.2.3/lib/logstash/outputs/http.rb:124:in `multi_receive'", "org/logstash/config/ir/compiler/OutputStrategyExt.java:114:in `multi_receive'", "org/logstash/config/ir/compiler/AbstractOutputDelegatorExt.java:97:in `multi_receive'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:373:in `block in output_batch'", "org/jruby/RubyHash.java:1343:in `each'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:372:in `output_batch'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:324:in `worker_loop'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:286:in `block in start_workers'"], :will_retry=>true}
[2020-05-27T16:19:37,869][INFO ][logstash.outputs.http ] Retrying http request, will sleep for 0 seconds
my server is working fine through the curl command I'm able to send the data.
and also I tried the same code in other system with logstash 6.8.9 version, there it is working without any issue.
can any one suggest why this error is occurring?
I've just deployed a node.js - vue.2.0 app to Google Cloud .
The vue.js 2.0 app is inside of the public node directory . Everything runs fine, except that all my queries to the web services are failing , inside of the habitual app.js node file, you know .. There are not calls to any other node server, that is why i even have tried localhost:8080 as a server name.
https://cedar-network-259109.appspot.com
All back end queries done from the app are failing :
POST
http://localhost:8080/getUsers
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8080/getUsers. (Reason: CORS request did not succeed).
I've also managed the app to call the google cloud server url : same error .
POST http://cedar-network-259109.appspot.com:8080/getUsers
It doesnt work neither.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8080/getUsers. (Reason: CORS request did not succeed).
This app is correctly working when deployed on openode.io host : http://vue-starter-webpack-cli-4-node.openode.io/.
MongoDb Atlas is connected (0.0.0.0 wildcard).
QUESTION :
Do I have to configure cors on my google cloud app with this doc , using the strange command? :
https://cloud.google.com/storage/docs/configuring-cors
Thanks a lot !
EDIT : This is what I got when asking about my cors config, it looks like I haven't got any cors config ? :
C:\UwAmp\www\vue-starter-webpack-cli-4-node-gcloud>gsutil cors get gs://cedar-network-259109.appspot.com
gs://cedar-network-259109.appspot.com/ has no CORS configuration.
EDIT 2 :
I'm sending a CORS params to my google cloud app like this :
>gsutil cors set cors-json-file.json gs://cedar-network-259109.appspot.com
This is my cors-json-file.json file :
[
{
"origin": ["https://cedar-network-259109.appspot.com"],
"responseHeader": ["Content-Type"],
"method": ["GET", "POST","HEAD", "DELETE"],
"maxAgeSeconds": 3600
},
{
"origin": ["https://cedar-network-259109.appspot.com:8080"],
"responseHeader": ["Content-Type"],
"method": ["GET", "POST","HEAD", "DELETE"],
"maxAgeSeconds": 3600
}
]
There is still an error :
POST https://cedar-network-259109.appspot.com:8080/getUsers
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cedar-network-259109.appspot.com:8080/getUsers. (Reason: CORS request did not succeed).
There are my informations :
>gsutil cors get gs://cedar-network-259109.appspot.com
[{"maxAgeSeconds": 3600, "method": ["GET", "POST", "HEAD", "DELETE"], "origin": ["https://cedar-network-259109.appspot.com:8080"], "responseHeader": ["Content-Type"]}]
And my Request URL:https://cedar-network-259109.appspot.com:8080/getUsers headers :
Host: cedar-network-259109.appspot.com:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: application/json, text/plain, */*
Accept-Language: fr,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://cedar-network-259109.appspot.com/
Origin: https://cedar-network-259109.appspot.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
My app.yaml file :
runtime: nodejs
env: flex
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
EDIT 3 : Modified my node app.js backend with this code :
const cors = require("cors");
app.use(
require("cors")({
origin: function(origin, callback) {
callback(null, origin);
},
credentials: true
})
);
to this :
app.use(
require("cors")({
origin: "https://cedar-network-259109.appspot.com",
credentials: true
})
);
With no luck ! Please help me !
If the resources you are trying to access are stored on Google Cloud Storage then you'll need to enable CORS as explained on the documentation you mention. If the resources you are trying to access files hosted by another Google App Engine app you need to modify your app.yaml file as explained on the documentation.
I have some issues while trying to publish a nuxtjs site. Usually, I was using the generate command, but for this one I need to go full SSR, so I'm going for nuxt start.
But after building and starting the app, it's a mess. The build goes perfectly in the console, and the application start. The problem is when I try to access the site, it loads partially, but I got all these errors in the browser:
manifest.3a7efd91c5f63f114507.js
Failed to load resource: the server responded with a status of 404 ()
vendor.7519259bf7bdf608079e.js
Failed to load resource: the server responded with a status of 404 ()
app.a5cb9356f53306f973dc.js
Failed to load resource: the server responded with a status of 404 ()
default.1f3ad14df16ee86595af.js
Failed to load resource: the server responded with a status of 404 ()
index.260dc65b69022a31ad58.js
Failed to load resource: the server responded with a status of 404 ()
/_nuxt/pages/spot/_slug.e57cc2e78d8e0b160fe7.js
Failed to load resource: the server responded with a status of 404 ()
manifest.3a7efd91c5f63f114507.js
Failed to load resource: the server responded with a status of 404 ()
default.1f3ad14df16ee86595af.js
Failed to load resource: the server responded with a status of 404 ()
index.260dc65b69022a31ad58.js
Failed to load resource: the server responded with a status of 404 ()
vendor.7519259bf7bdf608079e.js
Failed to load resource: the server responded with a status of 404 ()
app.a5cb9356f53306f973dc.js
Failed to load resource: the server responded with a status of 404 ()
Nothing seems wrong during the build. When I use nuxt start, I get this:
$ nuxt start
nuxt:axios BaseURL: http://localhost:3042/api (Browser: /api) +0ms
OPEN http://localhost:3042
Here's my server conf file:
# Site global
server {
listen 443 ssl http2;
server_name www.mywebsite.com;
access_log off;
location = /robots.txt { access_log off; log_not_found off; }
location = /favicon.ico { access_log off; log_not_found off; }
location / {
proxy_pass http://127.0.0.1:3042/;
include /etc/nginx/conf.d/proxy.conf;
root /var/www/mywebsite/site;
add_header Access-Control-Allow-Origin *;
}
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
root /var/www/mywebsite/site/;
expires 30d;
}
ssl_certificate /etc/letsencrypt/live/www.mywebsite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.mywebsite.com/privkey.pem;
}
# Redirection
server {
listen 80;
server_name mywebsite.com www.mywebsite.com;
location / {
return 301 https://www.mywebsite.com$request_uri;
}
}
And my nuxt config file:
const pkg = require('./package')
module.exports = {
mode: 'universal',
loading: { color: '#bb2b4d' },
router: {
linkActiveClass: '-active',
base: '/'
},
css: ['#/assets/icons/css/icons.css', '#/assets/snickles/snickles.css'],
plugins: ['~plugins/vue-filters.js', '~plugins/vue-modal.js'],
minify: {
removeEmptyAttributes: false,
collapseWhitespace: true,
conservativeCollapse: true,
collapseBooleanAttributes: true,
removeTagWhitespace: false,
removeStyleLinkTypeAttributes: true
},
modules: [
'#nuxtjs/axios'
],
axios: {
},
env: {
api: {
spots: `https://rest.mywebsite.com/spots`
}
},
proxy: {
},
build: {
extend(config, ctx) {
// Run ESLint on save
if (ctx.isDev && ctx.isClient) {
config.module.rules.push({
enforce: 'pre',
test: /\.(js|vue)$/,
loader: 'eslint-loader',
exclude: /(node_modules)/
})
}
}
},
postcss: [require('autoprefixer')],
vendor: ['moment', 'vue-js-modal']
}
Did I forget anything?
The most strange part is that it works perfectly well when I do the same on my own pc and not on my server. I checked the npm and node versions, they are the same (latest to date). Also, if testing with a demo template from NuxtJS, it works perfectly with the exact same server configuration.
By the way, the server is a debian 8, with all packages up to date.
Thanks in advance for any hint.
Edit: If of any use, the error log:
2018/02/14 19:12:54 [error] 12981#12981: *239930 open() "/var/www/mywebsite/site/_nuxt/pages/spot/_slug.e57cc2e78d8e0b160fe7.js" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx., server: www.mywebsite.com, request: "GET /_nuxt/pages/spot/_slug.e57cc2e78d8e0b160fe7.js HTTP/2.0", host: "www.mywebsite.com", referrer: "https://www.mywebsite.com/"
2018/02/14 19:12:57 [error] 12981#12981: *239930 open() "/var/www/mywebsite/site/_nuxt/manifest.3a7efd91c5f63f114507.js" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: www.mywebsite.com, request: "GET /_nuxt/manifest.3a7efd91c5f63f114507.js HTTP/2.0", host: "www.mywebsite.com", referrer: "https://www.mywebsite.com/"
2018/02/14 19:12:57 [error] 12981#12981: *239930 open() "/var/www/mywebsite/site/_nuxt/vendor.7519259bf7bdf608079e.js" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: www.mywebsite.com, request: "GET /_nuxt/vendor.7519259bf7bdf608079e.js HTTP/2.0", host: "www.mywebsite.com", referrer: "https://www.mywebsite.com/"
2018/02/14 19:12:57 [error] 12981#12981: *239930 open() "/var/www/mywebsite/site/_nuxt/app.a5cb9356f53306f973dc.js" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: www.mywebsite.com, request: "GET /_nuxt/app.a5cb9356f53306f973dc.js HTTP/2.0", host: "www.mywebsite.com", referrer: "https://www.mywebsite.com/"
Again, it’s working perfectly fine with other nuxt projects, with a similar configuration. Indeed it can’t find these files in this folder, as they’re not in it — which is perfectly normal. It’s up to the app to get the routes to these files, which it usually does pretty well, with the same directory output (as I said, it’s supposed not to be in a _nuxt folder).
Thanks.
This was tagged with nginx, so, here's the nginx way of solving the problem.
After the troubleshooting through the comments, you report receiving the following in your error_log:
2018/02/14 19:12:57 [error] 12981#12981: *239930 open() "/var/www/mywebsite/site/_nuxt/manifest.3a7efd91c5f63f114507.js" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: www.mywebsite.com, request: "GET /_nuxt/manifest.3a7efd91c5f63f114507.js HTTP/2.0", host: "www.mywebsite.com", referrer: "https://www.mywebsite.com/"
Subsequently, running find / -type f -name manifest.3a7efd91c5f63f114507.js, or similar, results in the corresponding file being located in /var/www/mywebsite/site/.nuxt/dist.
As such, your nginx configuration is wrong, because you make it look for these things in the incorrect folder — your config has root /var/www/mywebsite/site/; instead.
The proper way would may be to use a prefix-based location together with the alias directive:
location /_nuxt/ {
alias /var/www/mywebsite/site/.nuxt/dist/;
}
However, if /_nuxt/ has stuff that may have to be proxy_pass'ed to the upstream, and you want to continue using the pcre-based location you already have had in your original config, then an alternative solution like below is also an option (otherwise, you obviously would have to remove it as redundant, to make sure that the prior prefix-based location works, see http://nginx.org/r/location):
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
rewrite ^/_nuxt(/.*) $1 break;
root /var/www/mywebsite/site/.nuxt/dist/;
}
It seems PHP's built-in cURL module changes the header fields before sending them.
I developed a small class to communicate with an encoder device trough HTTP requests, using cURL to do the task. The code works fine under Windows, however, when I run it under Debian, the device responds with an HTTP 406 error.
The error code indicates that the server cannot respond in the requested format. (More info)
This is strange, since the response type is determined by the extension of the URL (and the possible modes are xml and json), and I didn't set explicitly the Accept parameter in the header.
Using the CURLOPT_VERBOSE parameter, it dumps the following data:
* Hostname was NOT found in DNS cache
* Trying 172.19.0.9...
* Connected to 172.19.0.9 (172.19.0.9) port 1080 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=US; ST=Illinois; L=Lake Forest; O=Haivision Network Video, Inc.; OU=PRODUCT DEVELOPMENT; CN=localhost.localdomai n; emailAddress=support#haivision.com
* start date: 2016-01-22 14:40:48 GMT
* expire date: 2026-01-19 14:40:48 GMT
* issuer: C=US; ST=Illinois; L=Lake Forest; O=Haivision Network Video, Inc.; OU=PRODUCT DEVELOPMENT; CN=localhost.localdomain ; emailAddress=support#haivision.com
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> POST /ecs/auth.xml HTTP/1.1
Host: 172.19.0.9:1080
Accept: */*
Content-Length: 86
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 86 out of 86 bytes
< HTTP/1.1 406 Not Acceptable
* Server nginx is not blacklisted
< Server: nginx
< Date: Fri, 01 Apr 2016 08:45:30 GMT
< Content-Type: application/xml
< Content-Length: 135
< Connection: keep-alive
<
* Connection #0 to host 172.19.0.9 left intact
It looks like the Content-Type: application/xml changed to application/x-www-form-urlencoded, and I think this is the main reason why the request fails so miserably.
The array being passed to the curl_setopts() function looks like this:
array(11) {
[19913]=>
bool(true)
[64]=>
bool(false)
[52]=>
bool(false)
[68]=>
int(10)
[10023]=>
array(5) {
["Authorization"]=>
string(10) "Basic ==Og"
["Cache-Control"]=>
string(8) "no-cache"
["Content-Type"]=>
string(15) "application/xml"
["Connection"]=>
string(10) "keep-alive"
["Content-Length"]=>
int(86)
}
[20079]=>
array(2) {
[0]=>
object(Pest)#43 (6) {
["curl_opts"]=>
array(9) {
[19913]=>
bool(true)
[64]=>
bool(false)
[52]=>
bool(false)
[68]=>
int(10)
[10023]=>
array(0) {
}
[20079]=>
*RECURSION*
[81]=>
int(0)
[84]=>
int(2)
[41]=>
bool(true)
}
["base_url"]=>
string(23) "https://172.19.0.9:1080"
["last_response"]=>
NULL
["last_request"]=>
NULL
["last_headers"]=>
NULL
["throw_exceptions"]=>
bool(true)
}
[1]=>
string(13) "handle_header"
}
[81]=>
int(0)
[84]=>
int(2)
[41]=>
bool(true)
[10036]=>
string(4) "POST"
[10015]=>
string(86) "<?xml version="1.0" encoding="UTF-8"?>
<user username="#########" password="########"/>
"
As you can see, there's no Accept tag, and the content type is set to application/xml.
So here's my question: why does curl changing the request's header? If the roots of the problem are something else, then what's the reason it works on Win10 and not on Debian Jessie?
Update (16. 04. 04.):
Fun thing, that the same version of cURL library doesn't work in PHP, but it does in cli:
curl -X POST -H "Authorization: Basic aGFpYWRtaW46bWFuYWdlcg==" -H "Content-Type: application/xml" -H "Cache-Control: no-cache" -H "Postman-Token: 760f1aac-619f-4b64-ec06-0146554fcecf" -d '<?xml version="1.0"?><user username="########" password="#######" />' "https://172.19.0.9:1080/ecs/auth.xml"
<?xml version="1.0"?>
<sessionid value="fd7b8fd0-ac5e-4f72-a01c-142082de24f1"/>
CURL version on the linux box is 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0.
Thanks in advance, and sorry for the wall of text.