Google compute engine console return 399 error code - google-compute-engine

When I try to reach (after login) https://cloud.google.com/console I get a 399 error code:
Remote Address:212.179.154.246:443
Request URL:https://cloud.google.com/console
Request Method:GET
And the response headers are:
HTTP/1.1 399 Internal Server Error
status: 399 Internal Server Error
version: HTTP/1.1
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-encoding: gzip
content-length: 141
content-type: text/html; charset=utf-8
date: Tue, 13 May 2014 12:01:20 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: Google Frontend
strict-transport-security: max-age=31536000
vary: Accept-Encoding
x-frame-options: DENY
x-pan-versionid: racy-novel-20140502-rc22.375698005067444148
Any idea why this is happening?
Using other devices works, and sometimes using the incognito mode works as well.
Thanks!


That's a strange error! Perhaps try connecting directly to the new console at https://console.developers.google.com/ ?

Related

Adding HTST header in my internal website doesn't work as expected

I have created a website where I am trying to add the HSTS security header via httpd.conf
<IfModule mod_headers.c>
Header always set Strict-Transport-Security 'max-age=4000; includeSubDomains'
</IfModule>
Adding the above code, able to see the Strict-Transport-Security header added over my HTTPS response header
host> curl -v https://172.21.218.67 --insecure
* About to connect() to 172.21.218.67 port 443 (#0)
* Trying 172.21.218.67... connected
* Connected to 172.21.218.67 (172.21.218.67) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* subject: ****************************************
* start date: Oct 21 06:42:49 2019 GMT
* expire date: Nov 20 06:42:49 2019 GMT
* common name: Insights
* issuer: *****************************************
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 172.21.218.67
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 21 Oct 2019 10:50:54 GMT
< Server: Apache
< Strict-Transport-Security: max-age=4000; includeSubDomains
< Last-Modified: Mon, 21 Oct 2019 08:58:58 GMT
< ETag: "8f3-59567e4f07362"
< Accept-Ranges: bytes
< Content-Length: 2291
< Content-Type: text/html
But this does create an impact over my website by the browser. (Browser is not redirecting to HTTPS if the user tries to access my website via HTTP).
I could not even see my website listing in chrome's HSTS checklist
chrome://net-internals/#hsts
Do I need to add any other configuration in order to make it work?

As suggested by IMSoP, my test server was not trusted by the server which affected the HSTS functionality.
Solved: Made my test server as a trusted source to the browser by adding a self-signed certificate.
Now the HSTS working as expected.

Cloudfront CDN Font blocked by CORS policy blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource

I'm using a nginx as my host and a Amazon Cloudfront as my cdn.
my header from my cdn has the Access-Control-Allow-Origin set to *
From my site:
curl -I http://example.com/ThemeIcons.woff?387osh
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 08 Dec 2016 03:01:23 GMT
Content-Type: application/font-woff
Content-Length: 18068
Last-Modified: Sat, 25 Jul 2015 05:35:17 GMT
Connection: keep-alive
ETag: "55b32015-4694"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Access-Control-Allow-Origin: *
Accept-Ranges: bytes
From my cdn site:
curl -I http://cdn.example.com/ThemeIcons.woff?387osh
HTTP/1.1 200 OK
Content-Type: application/font-woff
Content-Length: 18068
Connection: keep-alive
Server: nginx
Date: Thu, 08 Dec 2016 03:01:35 GMT
Last-Modified: Sat, 25 Jul 2015 05:35:17 GMT
ETag: "55b32015-4694"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Access-Control-Allow-Origin: *
Accept-Ranges: bytes
X-Cache: Miss from cloudfront
Via: 1.1 251651f117f01cad42a0ea283b85cb0a.cloudfront.net (CloudFront)
X-Amz-Cf-Id: iFxwbrqD8DWkxlnqsvFMHnO6M4BLU5bywk5MsicXZ00whNzV32U_Rw==
but still the message in chrome console showed,
Access to Font at
'http://cdn.example.com/ThemeIcons.woff?387osh'
from origin 'http://cdn.example.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://example.com' is therefore not allowed access.
I have researched this for 2 days, is there anyone can help me out ? Thanks!

Did you figure it out yet? A link to your cdn or the website that was to use the cdn would be helpful.
It could be that Chrome does a preflight OPTIONS request to your distribution, and that your origin doesn't have the header set for that. You can check this with
curl -I -X OPTIONS http://cdn.example.com/ThemeIcons.woff?387osh

httpd-2.4.18 mod_http2 works with curl and nghttp but doesn't work with the browser

I have installed httpd-2.4.18 with nghttp 1.6.0 and curl 7.46 to work with an http2 server. It seems that the server works with http2 when I test it with Curl and nghttp comands (as you can see below), but when I use the browser( Google Chrome 47.0.2526.106) the response headers are http1 instead of http2, and the Spdy indicator is grey (should be blue). Does anybody know why?
Commands Used
Curl command used that says me that http2 works properly:
eloy#eloy-OptiPlex-745:/usr/local/apache2/logs$ curl --http2 -I http://localhost
HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade
HTTP/2.0 200
date:Thu, 07 Jan 2016 21:38:06 GMT
server:Apache/2.4.18 (Unix) OpenSSL/1.0.2e
last-modified:Mon, 11 Jun 2007 18:53:14 GMT
etag:"2d-432a5e4a73a80"
accept-ranges:bytes
content-length:45
content-type:text/html
The same with nghttp2, it seems that http2 server is working properly with the following command:
eloy#eloy-OptiPlex-745:/usr/local/apache2/logs$ nghttp -uv http://localhost
[ 0.000] Connected
[ 0.000] HTTP Upgrade request
GET / HTTP/1.1
host: localhost
connection: Upgrade, HTTP2-Settings
upgrade: h2c
http2-settings: AAMAAABkAAQAAP__
accept: */*
user-agent: nghttp2/1.6.0
[ 0.001] HTTP Upgrade response
HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade
[ 0.001] HTTP Upgrade success
[ 0.001] recv SETTINGS frame <length=6, flags=0x00, stream_id=0>
Response headers from browser:
HTTP/1.1 304 Not Modified
Date: Thu, 07 Jan 2016 21:49:40 GMT
Server: Apache/2.4.18 (Unix) OpenSSL/1.0.2e
Connection: Upgrade, Keep-Alive
Keep-Alive: timeout=5, max=100
ETag: "2d-432a5e4a73a80"
Request Headers from browser:
GET / HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: es-ES,es;q=0.8
If-None-Match: "2d-432a5e4a73a80"
If-Modified-Since: Mon, 11 Jun 2007 18:53:14 GMT

Browsers do not support HTTP/1.1 to HTTP/2 upgrade requests.
The only way to use HTTP/2 from browsers is via TLS and ALPN.
Having said that, your "Request headers from browser" above are actually response headers and viceversa, so it's difficult to tell what you are actually doing. The request headers lack the necessary upgrade bits.
If you make a clear-text request from a browser (i.e. using the http scheme), then the browser will not try to upgrade and you will stay in HTTP/1.1 mode.

Chrome is not caching JS and CSS

I am running an expressjs server and tested caching in Chrome and Firefox. The headers are shown after the questions.
Could anyone tell me why Chrome is not caching JS and CSS files?
How to make Chrome cache the files?
Chrome request headers (initial and repeated):
GET /js/app.js HTTP/1.1
Host: 10.64.30.105
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Referer: https://10.64.30.105/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
Chrome response headers (initial and repeated):
HTTP/1.1 200 OK
Access-Control-Allow-Origin:
Access-Control-Allow-Credentials:
Access-Control-Allow-Methods:
Access-Control-Allow-Headers:
Accept-Ranges: bytes
Date: Thu, 12 Nov 2015 22:16:57 GMT
Cache-Control: public, max-age=31536000
Last-Modified: Thu, 12 Nov 2015 16:02:47 GMT
ETag: W/"XsMH2eh+CkXmU96uopajGg=="
Content-Type: application/javascript
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: keep-alive
Transfer-Encoding: chunked
The same request is cached in Firefox.
Firefox initial request headers:
GET /js/app.js HTTP/1.1
Host: 10.64.30.105
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://10.64.30.105/
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Firefox initial response headers:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Date: Thu, 12 Nov 2015 22:30:27 GMT
Cache-Control: public, max-age=31536000
Last-Modified: Thu, 12 Nov 2015 16:02:47 GMT
Etag: W/"XsMH2eh+CkXmU96uopajGg=="
Content-Type: application/javascript
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: keep-alive
Transfer-Encoding: chunked

There is a problem with gzipped resources like .js .css and the Vary: Accept-encoding Header with Chrome.
Please check my Anwser given here: https://stackoverflow.com/a/40726246/135785
This solved the problem for me:
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
BrowserMatch "Chrome" ChromeFound
Header append Vary Accept-Encoding env=!ChromeFound
</FilesMatch>
Check your Apache Config for "Header append Vary Accept-Encoding"

Getting duplicate http requests when setting content-type to utf-8 inside http-equiv meta tag

I've found in my site that I'm getting the http requests twice. I'm using an apache2 server. For example I visit index.php and I get 2 different header requests for index.php (images and CSS files are only requested once), so the page is served twice and any database operation is done twice.
I've found that this is being caused by the meta tag, http-equiv. When I set the content-type attribute to UTF-8 I get this behaviour, removing the tag or setting it to another encoding type (such as ISO-8859-1) eliminates this issue.
This is the html code for that meta-tag:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
Here are the sent and received headers caught by Http Headers Live plugin, that show the duplicate request:
http://oposiziones.dev/
GET / HTTP/1.1
Host: oposiziones.dev
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://oposiziones.dev/error-53_q0.html
Cookie: PHPSESSID=jeup12fp5lpoo5t9k052qt7tl7
HTTP/1.1 200 OK
Date: Mon, 21 Nov 2011 11:53:25 GMT
Server: Apache/2.2.20 (Ubuntu)
X-Powered-By: PHP/5.3.6-13ubuntu3.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 6496
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
http://oposiziones.dev/
GET / HTTP/1.1
Host: oposiziones.dev
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://oposiziones.dev/error-53_q0.html
Cookie: PHPSESSID=jeup12fp5lpoo5t9k052qt7tl7
HTTP/1.1 200 OK
Date: Mon, 21 Nov 2011 11:53:26 GMT
Server: Apache/2.2.20 (Ubuntu)
X-Powered-By: PHP/5.3.6-13ubuntu3.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 6385
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
Anybody with an idea on how to solve this? I need to keep the UTF-8 encoding because my database data is set to UTF-8, and everything should be encoded to UTF-8.
I guess this is an apache encoding issue, but have no idea why this happens.
Thanks in advance!

I didn't find why is happening this but, I solved the issue by adding this directive to the apache configuration file.
Added to config file /etc/apache2/conf.d/charset
AddDefaultCharset UTF-8
This option overrides any http-equiv charset meta tag, so the content is always sent in utf-8. This is no problem if all your content should be sent in that encoding, but won't be a solution if you use several types of encoding.
You can move this configuration directive to your .htaccess so it doesn't affect the whole server, just the folder/site you want to.