I have an IIS10 Webserver and multiple sites on it.
Now I have experienced something quite odd. If I connect to the website via the internet (external network) everything seems fine and all configured Response Headers (Tried both setting them in web.config and in the IIS Feature "HTTP Response Headers) are returned. But when I access the same URL via an Computer on the same network, then most of the configured headers are missing.
Here are the settings on the IIS Server
IIS Server Config
Here is the response I get over the internet (Access-Control Headers are added over ASP.NET global.asax):
Response Headers Remote
and here's the Response Headers when accessing the same URL over a machine in the same network:
Response Headers Same Network Machine
as you can see, the Header "Body-Count" is not present on the machine in the same network. But the X-Powered-By is. If I remove the X-Powered-By Header, then it is not present on both machines. I know that the X-Powered-By Header is configured on the Root of the IIS Server, but if I add any other Response Headers there I get an 500 Internal Server error on all of my requests as a response...
Related
Cannot load Apollo Server on safari. It returns an error that reads.
Safari does not support network requests from Studio on HTTPS to your local HTTP endpoint, so we cannot introspect your endpoint.
There are a couple solutions:
Visit this page from a browser that supports HTTPS requests to local HTTP endpoints, like Chrome or Firefox.
Set up an SSL certificate for your local endpoint.
Decided to try the second solution by spinning up ngrok. Which also returns a [Error] Fetch API cannot load https://7676-576-98-1-248.ngrok.io/ due to access control checks.
I am passing the Access-Control-Allow-Origin and Access-Control-Allow-Credentials Headers.
Any guess on what can be done?
I'm a requesting a url with fetch in my node app and the response status is 464 (without responseText and without any error message). But I could't find any info about that.
Also if I request the same url with my browser (Chrome) then it works fine (no need to send any cookies or auth, it works in incognito window too)
What could be causing this?
EDIT: seems to be a problem with AWS Load Balancer, my problem is exactly this:
https://forums.aws.amazon.com/message.jspa?messageID=964799
But there's no solution in that post, so maybe could be helpful to put it here if someone knows the problem (I'm suspecting is related with HTTP 2.0 but not sure, could it be?)
Response Header in Node is:
Server=awselb/2.0
Content-Length=0
HttpCode=464
But in Chrome:
server: nginx/1.18.0
I had this issue just today. My target group was configured for HTTP/2, but, the backend service was not prepared for that traffic. So, when I rebuilt the target group using HTTP/1.1, traffic began to function as expected.
When creating a target group, the options presented to me for HTTP protocol options were (as shown in the AWS Console):
HTTP/1.1
Send requests to targets using HTTP/1.1. Supported when the request
protocol is HTTP/1.1 or HTTP/2.
HTTP/2
Send requests to targets using HTTP/2. Supported when the request
protocol is HTTP/2 or gRPC, but gRPC-specific features are not
available.
I have a RESTApi application which I have recently moved over to Microsoft Azure App-services. Earlier it was hosted on a Linux server. The issue that I am seeing is weird:
When a client using ASP.net call a POST request with no body and no content-length header explicitly passed, the request fails with 411 Content-length required error. For the same client, the requests which were going on to the Linux server are still working fine.
For a client using python/PHP, the same request works on both the IIS and Linux environments.
I am unable to understand why this might be happening. I have resolved the issue by sending content-length:0 for this API call but want to understand why this is happening.
I have a server over HTTPS on NodeJS with Express.
When uploading a file, I have used the req.protocol directive in the controller to get either the HTTP or HTTPS "part" of the URL, so that I can save the file with the absolute URL. The problem is that without enabling the "trust proxy" setting of express (http://expressjs.com/en/api.html#trust.proxy.options.table), HTTPS doesn't get detected.
I thought this setting was used in the case of the actual redirect (when using the HTTP URL and the server doing the 301 redirect to HTTPS).
So this is more of an explanation question, rather than a solution one:
Why doesn't the HTTPS get detected when calling the URL through that?
trust proxy has nothing to do with 301 redirects.
That settings is important when running your node server behind a proxy:
+----------HTTPS--------+---HTTP---+
| | |
client --> internet --> proxy --> node.js
It is typical that you have some sort of proxy between the internet and your node server; for example a CDN server, a load balancer, or simply an nginx instance or such. The HTTPS connection is established between the client and that proxy. The proxy cares about the necessary wrangling of the SSL certificate and encrypting the connection and doesn't burden your application server (node) with those details. It is then forwarding only the relevant details of the request via plain HTTP to your node server. Your server only sees the proxy as the origin of the request, not the client.
Since the node server didn't itself handle the HTTPS connection, how could it know whether the connection between the client and the proxy was HTTPS? It can't. The proxy needs to voluntarily forward that information too. It does so in the X-Forwarded-* HTTP headers. The information whether it was specifically HTTP or HTTPS is sent in the X-Forwarded-Proto header.
The thing is, those are just HTTP headers. Anyone can set those headers. The client itself could set those headers. That's why you need to explicitly opt into using those headers with the trust proxy setting, iif and when you know your app will be running behind a proxy which sets those headers. When you're not running behind a proxy but your node server is directly exposed to the internet, you must switch that setting off; otherwise anyone could set those headers, your server would obey those headers and be lead to use false information.
I have this IIS7.5 with ARR installed on and configured as a reverse proxy to another server which is running IIS7.
On this IIS7.5 I have ASP.NET 4 applications and simple websites installed.
Since configuring a farm on this IIS7.5 running it as a reversed proxy, the local application doesn't run with this error message:
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.
Will it be possible to run both local application and routing (reverse proxy) on this IIS7.5 at the same time or should I give up and move the applications to other servers?
Application request routing operates as a server-wide URL-rewriter.
This means that it captures all traffic coming to a box.
You can still host an IIS website on the same box, but you need to make sure that ARR leaves the requests for this site alone.
I set this up so that the ARR rule, while still remaining a wildcard *, I make sure that part of the match conditions is for requests to my local site to be left alone.
There are a number of conditions you can use to create a does not match rule.
Ive used:
{HTTP_HOSTNAME} if you are just doing HTTP requests and just want certain domain names to be left alone.
{SERVER_PORT} if you're hosting an SSL site and are the only one on the box.
{LOCAL_ADDR} if your site sits on a dedicated IP address.
many more.... really you just need to set up rules that exclude your locally hosted website.