I've been accessing Plesk Admin for a while at http://yourarthere.net:8443 but since I moved to a new home and ISP (Comcast) I am unable to get to the page using a browser or UNIX wget.
# wget http://yourarthere.net:8443
--2011-08-22 21:13:06-- http://yourarthere.net:8443/
Resolving yourarthere.net (yourarthere.net)... <IP>
Connecting to yourarthere.net (yourarthere.net)|<IP>|:8443...
connected.
HTTP request sent, awaiting response... ^C <canceled>
I can however access the page using my phone or another ISP.
The strange thing is that I can access the page from my home if I use a secure connection. I've been told that Plesk should forward to https automatically from http anyway but it isn't for some reason from my ISP (Comcast).
In addition, a second, possibly related issue, is that I am receiving a message that there is a problem with my security certificate. But again, it only happens when I connect from my ISP.
# wget https://yourarthere.net:8443/
--2011-08-23 14:02:40-- https://yourarthere.net:8443/
Resolving yourarthere.net (yourarthere.net)... 69.64.52.141
Connecting to yourarthere.net (yourarthere.net)|69.64.52.141|:8443... connected.
ERROR: cannot verify yourarthere.net’s certificate, issued by “/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287”:
Self-signed certificate encountered.
To connect to yourarthere.net insecurely, use ‘--no-check-certificate’.
Here is the result from a colleague's attempt from a different ISP:
# wget http://yourarthere.net:8443
--2011-08-23 14:41:53-- http://yourarthere.net:8443/
Resolving yourarthere.net... 69.64.52.141
Connecting to yourarthere.net|69.64.52.141|:8443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://yourarthere.net:8443/ [following]
--2011-08-23 14:41:53-- https://yourarthere.net:8443/
Connecting to yourarthere.net|69.64.52.141|:8443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html.2'
The problem was due to a misconfigured SSL on the server which caused an error in the forwarding process. Problem fixed now.
Related
Background:
I have my personal website running on a lighttpd server on my raspberry pi. I have that server’s port (80) forwarded so it can be accessed publicly.
I’m in the process of making a project, and I want a node.js service to make requests to from the lighttpd server. I set up pm2 so the node.js server is always running. I have that port forwarded too (5000). I've verified that this server is working via postman and the browser
Problem:
I'm receiving the following error when making requests:
has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space private.
Of note; I have Access-Control-Allow-Private-Network:true in the response header and Access-Control-Request-Private-Network:true in the request header. The only other solution I've found that might fix this is getting an SSL cert for the lighttpd server and using https for it, however I'm struggling setting that up to see if it would work
Questions:
Would getting an SSL cert for lighttpd allow me to make requests to my pm2 server?
Is there a different solution?
How secure is this setup? I don't expect a lot of traffic...
My program sends http requests to https://auth.riotgames.com/api/v1/authorization server. As I understand it, cloudflare is installed there, which blocks my requests by issuing a 403 status code.
But the problem is that if I run the Http Debugger (https://www.httpdebugger.com/) the server responds fine. This is independent of the use of a proxy. Might have something to do with the certificates as I tried to connect with Fiddler installed on another machine (with Http Debugger running on my machine) and if Fiddler decrypts the http traffic it starts responding with 403, and if it doesn't decrypt it responds fine.
With Http Debugger:
With Http Debugger and Fiddler on another machine:
If it's not clear, ask questions. I will be glad to any suggestions, for me it is very important.
I am running an Nginx Ingress Controller and an Nginx reverse proxy in my Kubernetes cluster.
I started seeing an issue for just one user and it only started recently. That user keeps getting HTTP 502 from our Nginx.
When I send the same requests from my machine, they return HTTP 200. I also logged into the console of my NGINX container, and was able to execute the request that the redirect results in.
How else can I check the reason for HTTP 502? Are the responses from the address that I am redirected to visible anywhere?
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
These are both timeout errors, but who is timing out in a 408 vs. a 504?
From w3, 408 is defined as:
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
...And 504 is:
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
So who is the 'client' in the 408 if not an intermediary server? If it's an actual end user, how does a server know to wait for their request before they have made it?
The client is the browser or client application. The server knows to wait for a request because it has accepted a connection, or already read part of the request, say a header or two.
Amazon documentation tells: http://docs.aws.amazon.com/en_en/elasticloadbalancing/latest/classic/ts-elb-error-message.html#ts-elb-errorcodes-http408
Indicates that the client cancelled the request or failed to send a full request
Mozilla documentation tells: https://developer.mozilla.org/en/docs/Web/HTTP/Status/408
The HTTP 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client