I use Asp.net web from and IIS 8 and sometimes I saw this result instead of Html result in my browser:
I use "FortiWeb" as Web Application Firewall(WAF) and it configured to convert request http to https.
This error sometimes occurs in random page.
Am I mistaken in IIS setup?
For me it seems to me a normal Http 200 OK message.
It states "Content Encoding gzip" also.
Isn't it just a compressed version of the normal HTTP resonse? Which can happen if comression is enabled in your IIS configuration.
Related
I am trying to cache an api get request that produces json - using cloudflare by page rules : Cache Everything with Edge Cache TTL > 0.
No matter what I try - I am unable to get past: CF-Cache-Status: DYNAMIC!
Referring to the documentation of page rules I even tried a sample xml file - but the same issue persists.
Page rule:
https://.com:8443/cache_*
Cache Level: Cache Everything
Using cf workers too - availed no result. The api is being served by Spring Boot, have tried virtually all combination of headers. What am I doing wrong?
You'll want to read up on how to use Cache-Control header, as this will enable you to control the caching behavior on file types that Cloudflare would not normally cache -
https://developers.cloudflare.com/cache/about/cache-control
There are some cases where Cloudflare will never cache the response (for your safety) however. For example, if the server is returning a Set-Cookie response header.
Oops! I was using an unsupported port. Apparently 8443 in NOT supported for caching.
This was pointed out by M4rt1n at cloudflare forum:
https://community.cloudflare.com/t/unable-to-cache-json-api-with-page-rules-stays-at-dynamic/322632/4
https://support.cloudflare.com/hc/en-us/articles/218411427 > only port 80, 8080 & 443 supported for caching.
Cloudflare would have simply said - “8443 is not supported for caching” when i was trying to add the page rule with cache everything
I work in a corporate environment and found an issue I can't resolve.
It has to do with EventSource changing the URL param from HTTP to HTTPS.
const url = 'http://localhost:8080'; // <-- using HTTP not HTTPS
new window.EventSource(url);
Which results in the browser throwing this error:
GET https://localhost:8080 net::ERR_TUNNEL_CONNECTION_FAILED
I am developing on a website using HTTPS so maybe this is by design that it uses the same protocol. Anyone experienced this issue or know how to resolve it?
--- Update ---
Looks like it is by design. When attempting this on another HTTPS site I got this:
Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure EventSource endpoint 'http://localhost...'. This request has been blocked; the content must be served over HTTPS.
The question still remains, how do I get around this?
Eventsource won't change between http and https. Are you using the HTTPS Everywhere plugin for Chrome, or something like that?
I think you are being hit by the same-origin policy. What this means is that the SSE connection must be to the same origin, which basically means the same hostname and domain, same scheme (i.e. either both http or both https) and same port.
You can use CORS to get around this. At the top of your SSE script you need to send back this header:
Access-Control-Allow-Origin: *
This says anyone, from anywhere, is allowed to connect and get the data stream. It has to be done on the server script, there is no way to do it from the client. (By design: the whole point of same-origin policy is to stop people using other people's content and making it look like their own, without permission.)
Shameless Plug: see my chapter 9 in my book (Data Push Apps with HTML5 SSE, O'Reilly) for finer control of allow-origin, and how it interacts with cookies and basic auth.
BTW, I notice I mention that Chrome won't work with self-signed https certificates. To be honest I'm not sure if that is still the case, but that might also be something to watch out for when using https and localhost.
I want to create a cordova generic client for debug purpose. but I face the cross domain request problem. My case is:
1. I deploy my source code (html code) on a web server A.
2. My backend data source is from server B.
3. I create a cordova app and run on the device or simulator. the App access the url from server A and open the app page, that work fine. but when my js code read data from Server B, all request is failed. I guess it's cause by cross domain restriction.
Any one have solution to resolve this problem?
Thanks!
Well, since your initial HTTP request goes through and HTML is returned, it seems that the connection from the Cordova is working, at least for server A.
What you could try is to upload temporarily "content" to server A which you try to fetch with AJAX calls.
If that succeeds, you can be sure that the fault is on server B and CORS works okay from front-end. In which case you could try to access the A & B from web client etc. to see possible differences in response headers. The server B is in that case probably missing Access-Control-Allow-Origin: * header. Try to add it to your server configuration or try JSONP. Also as a long shot, read your config.xml if you have only allowed connections to server A with
<access origin="<server A>"/>
in which case you obviously need to allow server B too.
If that fails, there is much less to work with and I can only suggest you to study resources like enable-cors.org which demonstrate how to actually allow CORS.
I'm trying to do requests to my REST API, I have no problems with Firefox, but in Chrome I can't get the browser to work, always throws 200 OK, because no if-none-match (or similar) header is sent to the server.
With Firefox I get 304 perfectly.
I think I miss something, I tried with Cache-Control: max-age=10 to test but nothing.
One reason Chrome may not send If-None-Match is when the response includes an "HTTP/1.0" instead of an "HTTP/1.1" status line. Some servers, such as Django's development server, send an older header (probably because they do not support keep-alive) and when they do so, ETags don't work in Chrome.
In the "Response Headers" section, click "view source" instead of the parsed version. The first line will probably read something like HTTP/1.1 200 OK — if it says HTTP/1.0 200 OK Chrome seems to ignore any ETag header and won't use it the next load of this resource.
There may be other reasons too (e.g. make sure your ETag header value is sent inside quotes), but in my case I eliminated all other variables and this is the one that mattered.
UPDATE: looking at your screenshots, it seems this is exactly the case (HTTP/1.0 server from Python) for you too!
Assuming you are using Django, put the following hack in your local settings file, otherwise you'll have to add an actual HTTP/1.1 proxy in between you and the ./manage.py runserver daemon. This workaround monkey patches the key WSGI class used internally by Django to make it send a more useful status line:
# HACK: without HTTP/1.1, Chrome ignores certain cache headers during development!
# see https://stackoverflow.com/a/28033770/179583 for a bit more discussion.
from wsgiref import simple_server
simple_server.ServerHandler.http_version = "1.1"
Also check that caching is not disabled in the browser, as is often done when developing a web site so you always see the latest content.
I had a similar problem in Chrome, I was using http://localhost:9000 for development (which didn't use If-None-Match).
By switching to http://127.0.0.1:9000 Chrome1 automatically started sending the If-None-Match header in requests again.
Additionally - ensure Devtools > Network > Disable Cache [ ] is unchecked.
1 I can't find anywhere this is documented - I'm assuming Chrome was responsible for this logic.
Chrome is not sending the appropriate headers (If-Modified-Since and If-None-Match) because the cache control is not set, forcing the default (which is what you're experiencing). Read more about the cache options here: https://developer.mozilla.org/en-US/docs/Web/API/Request/cache.
You can get the wished behaviour on the server by setting the Cache-Control: no-cache header; or on the browser/client through the Request.cache = 'no-cache' option.
Chrome was not sending 'If-None-Match' header for me either. I didn't have any cache-control headers. I closed the browser, opened it again and it started sending 'If-None-Match' header as expected. So restarting your browser is one more option to check if you have this kind of problem.
I have deployed my asp.net MVC app to production, and it works as expected. However, when using F12 in IE to see the Network requests that are being made to the server, I see the requests being sent with this format:
http://172.16.10.2/VMSWebTest/(F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1))/Tiers
instead of this format:
http://172.16.10.2/VMSWebTest/Tiers
Where is that (F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1)) part of the URL coming from? Why? What is it's purpose?
I've noticed this only seems to be with IE, as the request url are as expected when using Chrome.
It might be that you are the victim of a bug where ASP.NET can not recognize IE10, please see the suggestions in this answer:
IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Specifically, there is a hotfix available: http://support.microsoft.com/kb/2600088