While generating the Reports under payroll module in local odoo server - I am getting the following error:
Odoo
XmlHttpRequestError Proxy Error
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em>POST /web/dataset/call_button</em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 192.168.111.188 Port 80</address>
</body></html>
I have the same problem when i try to create a new db
odoo 8.0.17 / bitnami stack
> XmlHttpRequestError Proxy Error <!DOCTYPE HTML PUBLIC "-//IETF//DTD
> HTML 2.0//EN"> <html><head> <title>502 Proxy Error</title>
> </head><body> <h1>Proxy Error</h1> <p>The proxy server received an
> invalid response from an upstream server.<br /> The proxy server could
> not handle the request <em><a
> href="/web/database/create">POST /web/database/create</a></em>.<p>
> Reason: <strong>Error reading from remote server</strong></p></p>
> </body></html>
Try these steps to solve the XmlHttpRequestError Proxy Error:
It is something related to browser end only so use Private Window
Clear Browser cookie because sometimes cookies are corrupted
Some times page actually loading but request time out
It Works For Me try this, you have to update your action module code(for example - model:employee.fine) with empty print statement or something else, now try that action again it works!
Related
I have an esp8266 which was directly sending http requests to http://fcm.googleapis.com/fcm/send but since google seems have stopped allowing requests to be send via http, I need to find a new solution.
I started down a path to have the esp8266 directly send the request via https and while it works on a small example the memory footprint required for the https request is to much in my full application and I end up crashing the esp8266. While there are still some avenues to explore that might allow me to continue to directly send messages to the server, I think I would like to solve this by sending the request via http to a local "server" raspberry pi, and have that send the request via https.
While I could run a small web server and some code to do handle the requests, it seems like this is exactly something traffic-server should be able to do for me.
I thought this should be a one liner. I added the following the the remap.config file.
redirect http://192.168.86.77/fcm/send https://fcm.googleapis.com/fcm/send
where 192.168.86.77 is the local address of my raspberry pi.
When I send requests to http://192.168.86.77/fcm/send:8080 I get back the following:
HTTP/1.1 404 Not Found
Date: Fri, 20 Sep 2019 16:22:14 GMT
Server: Apache/2.4.10 (Raspbian)
Content-Length: 288
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /fcm/send:8080 was not found on this server.</p>
<hr>
<address>Apache/2.4.10 (Raspbian) Server at localhost Port 80</address>
</body></html>
I think 8080 is the right port.
I am guessing this is not the one liner I thought it should be.
Is this a good fit for apache-traffic-controller?
Can someone point me to what I am doing wrong and what is the right way to accomplish my goal?
Update:
Based on Miles Libbey answer below, I needed to make the following update to the Arduino/esp8266 code.
Change:
http_.begin("http://fcm.googleapis.com/fcm/send");
To:
http_.begin("192.168.86.77", 8080, "http://192.168.86.77/fcm/send");
where http_ is the instance of the HTTPClient
And after installing trafficserver on the my raspberry pi, I needed to add the following two lines to the /etc/trafficserver/remap.config
map http://192.168.86.77/fcm/send https://fcm.googleapis.com/fcm/send
reverse_map https://fcm.googleapis.com/fcm/send http://192.168.86.77/fcm/send
Note the reverse_map line is only needed if you want to get feedback from fcm, ie if the post was successful or not.
I would try a few changes:
- I'd use map:
map http://192.168.86.77/fcm/send https://fcm.googleapis.com/fcm/send instead of redirect. The redirect is meant to send your client a 301, and then your client would follow it, which sounds like it'd defeat your purpose. map should have ATS do the proxying.
- I think your curl may have been off -- the port usually goes after the domain part -- eg, curl "http://192.168.86.77:8080/fcm/send". (and probably better:
curl -x 192.168.86.77:8080 "http://192.168.86.77:8080/fcm/send", so that the port isn't part of the remapping.
i'm trying of get a ssl with let's encrypt, i have nginx and nodejs but when i type this comand "sudo certbot --nginx -d simca.tech" appear this:
Failed authorization procedure. simca.tech (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://simca.tech/.well-known/acme-challenge/Kmjz6pdfz91ubRRrE_AL-qQ5Z-1FB7vfM3WSt6xuul8 [104.248.66.200]: "<!doctype html>\n<html lang=\"en\">\n<head>\n <meta charset=\"utf-8\">\n <title>Cliente</title>\n <base href=\"/\">\n\n <meta name=\"viewp"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: simca.tech
Type: unauthorized
Detail: Invalid response from
http://simca.tech/.well-known/acme-challenge/Kmjz6pdfz91ubRRrE_AL-qQ5Z-1FB7vfM3WSt6xuul8
[103.xxx.65.xxx]: "<!doctype html>\n<html lang=\"en\">\n<head>\n
<meta charset=\"utf-8\">\n <title>Cliente</title>\n <base
href=\"/\">\n\n <meta name=\"viewp"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
I'm running plesk 17 on a debian machine. One certificate could be signed without problems. But then I got this error:
Error: Let's Encrypt SSL certificate installation failed: Failed letsencrypt execution: Saving debug log to /opt/psa/var/modules/letsencrypt/logs/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mindmailer.de
http-01 challenge for www.mindmailer.de
Starting new HTTPS connection (1): 127.0.0.1
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. mindmailer.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mindmailer.de/.well-known/acme-challenge/Zg70UTECV4lP-E25ateUev3vsq5nCbX-4L-KUXwUU4I: "<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe", www.mindmailer.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.mindmailer.de/.well-known/acme-challenge/rreVCbEY8pX5eaWVMGiZsg2UxNennZfwkHC6WMAJV-Q: "<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: mindmailer.de
Type: unauthorized
Detail: Invalid response from
http://mindmailer.de/.well-known/acme-challenge/Zg70UTECV4lP-E25ateUev3vsq5nCbX-4L-KUXwUU4I:
"<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
Domain: www.mindmailer.de
Type: unauthorized
Detail: Invalid response from
http://www.mindmailer.de/.well-known/acme-challenge/rreVCbEY8pX5eaWVMGiZsg2UxNennZfwkHC6WMAJV-Q:
"<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
What could be the problem in this case?
DNS A records are on the right ip adress .. Any ideas?
Thanks
You have redirects, which conflicts with the Let's Encrypt - challenge ( => "marketing.mindmailer.de" ) and as you can see in your error - log, Let's Encrypt tries to write to "mindmailer.de/.well-known/acme-challenge/", which is not possible this way.
We have logger adapter "WLClientLogReceiver". When we tried to hit the REST service using below link to get adapter details we got 404 error
https://example.com/worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters/WLClientLogReceiver
Respnse:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters/WLClientLogReceiver was not found on this server.</p>
<hr>
<address>IBM_HTTP_Server at example.com Port 443</address>
</body></html>
The 404 seems to suggest the URL is wrong. If the URL were indeed proper , then a message such as - " The adapter \"WLClientLogReceiver\" of the runtime \"yourruntime\" does not exist in the MobileFirst administration database" is returned, in case you query for a missing adapter.
To test:
a)
The URL - "https://example.com/worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters?" returns metadata of all deployed adapters.
Check if you get the list of all adapters and see if WLClientLogReceiver is in the list.
b) If that also gives you a 404 :
If you are deployed on a standalone server, your admin context might be different - for standalone servers ,it is by default "wladmin" as opposed to "worklightadmin" in the Development server. Verify your context root.
I've come across an issue where a web application has managed to create a cookie on the client, which, when submitted by the client to Apache, causes Apache to return the following:
HTTP/1.1 400 Bad Request
Date: Mon, 08 Mar 2010 21:21:21 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Length: 7274
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Size of a request header field exceeds server limit.<br />
<pre>
Cookie: ::: A REALLY LONG COOKIE ::: </pre>
</p>
<hr>
<address>Apache/2.2.3 (Red Hat) Server at www.foobar.com Port 80</address>
</body></html>
After looking into the issue, it would appear that the web application has managed to create a really long cookie, over 7000 characters. Now, don't ask me how the web application was able to do this, I was under the impression browsers were supposed to prevent this from happening. I've managed to come up with a solution to prevent the cookies from growing out of control again.
The issue I'm trying to tackle is how do I reset the large cookie on the client if every time the client tries to submit a request to Apache, Apache returns a 400 client error? I've tried using the ErrorDocument directive, but it appears that Apache bails on the request before reaching any custom error handling.
Oh dear! I think you'll have to at increase the LimitRequestFieldSize configuration option in Apache's httpd.conf to go any further, so you can get as far as running the server-side script. Make sure it cleans up the cookies as quickly as possible before they start to grow again!