CloudFlare 宣佈支援 HTTP/2 的 Server Push

CloudFlare 宣佈支援 HTTP/2 的 Server Push:「Announcing Support for HTTP/2 Server Push」。

如同預期的 (最簡單的方式),是透過 HTTP header 標示,也就是透過 rel=preload 辨識:

Link: </asset/to/push.js>; rel=preload;

可以看到沒有 Server Push 與有 Server Push 的效能差異:

Google CDN 進入 Beta

最近 CDN 產業裡有不少蕭期,其中一個新聞是 Google CDN 進入 beta,Google 藉由在全球佈署的機房來服務。

不過雖然進入了 Beta,但仍然有很嚴重的技術限制,只能透過 GCE 當 origin server,這使得實用性低很多:

Origins
Delivers HTTP/HTTPS content originating from Compute Engine VM instances. External origin servers are not supported.

有些特點是跟一般 CDN 不同的,一個是 Google 對 HTTPS 的口號,所以 HTTP 與 HTTPS 的價錢相同。其實你就當做他把 HTTP 的費用收的跟 HTTPS 一樣就好:

SSL Shouldn't Cost Extra
The web is moving to HTTPS, and your cacheable content should, too. With Cloud CDN, you can secure your content using SSL/TLS for no additional charge.

另外一個特點是從技術上就宣稱完全使用 Anycast,而不是見到的 DNS + Anycast:

Anycast
Serve all your content from a single IP address with low latency worldwide.

另外,計價的方式與其他的 CDN 有不少地方不一樣,另外也有針對中國地區另外處理。

首先是他把 Cache Egress (從 CDN 給使用者) 與 Cache Fill (從 CDN 到 Origin 取得資源) 分開收,一的般 CDN 都只收 Cache Egress 這塊。

再來是中國大陸地區的價錢另外標示,有特地標明不是從中國大陸地區直接提供服務:

Traffic destined for mainland China is served from Google locations outside of mainland China. Performance and reliability may be lower than for traffic served from in-country locations.

言下之意就是另外買 optimized 的頻寬來服務,但還是不會像在中國大陸地區有機房的效果這麼好,不過好處是不需要 ICP 之類的證照。

不過不得不說價錢其實還蠻便宜的,無論是歐美還是亞洲區。

HPKP (HTTP Public Key Pinning) 常見的錯誤

Netcraft 因為有一套系統在觀察整個 internet 的架構,有時後會整理出一些有趣的東西,像是這次整理出來的 HPKP,就找出很多設定上的錯誤:「HTTP Public Key Pinning: You’re doing it wrong!」。

抓了一下列出來哪些:

  • Zero max-age:這個 XDDD
  • Wrong pin directives:沒寫 pin-sha256,包括寫成 pin-sha512 (RFC 不支援)、pin-sha1 (RFC 也是不支援)、pin-sha (RFC 還是不支援)、pin-sha245 (按歪了 XDDD)、ping-sha256 (XDDD)。
  • Only one pinned public key:HPKP 規定要有兩個 pinned public key。
  • No pins at all:因為 typo 而導致失效,像是忘記用雙引號包起來 (double quote,也就是「"」)。
  • At least two pins, but no backup pins:應該要是兩個完全獨立的 CA。
  • Setting HPKP policies over HTTP:這個會被直接忽略。
  • Not quite got round to it yet...:看到「Public-Key-Pins: TODO」也頗不賴 XDDD
  • Using HPKP headers to broadcast skepticism:跟上面那個有異曲同工的感覺 XDDD Public-Key-Pins: This is like the most useless header I have ever seen. Preventing MITM, c'mon, whoever can't trust his own network shouldn't enter sensitive data anywhere.
  • Violation reports that will never be received:有問題時的 report 送到有問題的 domain 上,於是就送不出去了 XD

GitHub 支援 HTTP Code 451 了...

GitHub 宣佈支援 HTTP Code 451 了:「The 451 status code is now supported」。也就是 RFC 7725 的「An HTTP Status Code to Report Legal Obstacles」。

目前會把因為 DMCA takedown notice 下架的內容以 HTTP Code 451 標出:

The GitHub API will now respond with a 451 status code for resources it has been asked to take down due to a DMCA notice.

HTTP Code 451 的點子出自「華氏 451 度」這本書,表示紙的燃點。

Go 1.6 把 HTTP/2 變成預設支援的功能

Go 的官方公告「Go 1.6 is released」提到了把 net/http 的 HTTP/2 預設啟用了:

In Go 1.6, support for HTTP/2 is enabled by default for both servers and clients when using HTTPS, bringing the benefits of the new protocol to a wide range of Go projects, such as the popular Caddy web server.

另外值得一提的是 sort 演算法的效能改善:

The algorithm inside sort.Sort was improved to run about 10% faster, but the change may break programs that expect a specific ordering of equal but distinguishable elements.

這應該算還蠻基本常用到的東西,會改善很多程式效能...

從 Chrome 50 開始,HTTP 網頁內將禁用 Geolocation 功能

Twitter 上看到如標題所說的,從 Google Chrome 50 開始 (現在正式版本是 48),HTTP 網頁將禁用 Geolocation API

對隱私保護的加強。

HTTP Status Code 451

前陣子送出的 HTTP Status Code 451 要通過成為標準了:「Why 451?」。

Today, the IESG approved publication of "An HTTP Status Code to Report Legal Obstacles". It'll be an RFC after some work by the RFC Editor and a few more process bits, but effectively you can start using it now.

取自「華氏451度」這部講出版物言論自由的作品 (紙的燃點是華氏 451 度),在 Internet 時代,451 剛好在 HTTP Status Code 4xx 的範圍,被拿來用做「因法令限制而服法提供內容的 Status Code」。

在文件開頭說明了這個代碼的用途:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content,瀏覽器預設值不會直接全部擋掉,而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換,讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後,接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了,接下來要不要進 HSTS Preload List 就看大家自己的想法了。

讓 nginx 看到 5xx 回應時,去另外一台有開 debug-mode 的 server 上再跑一次

Debug 模式會比一般的模式來的慢,但可以看到更多資訊。以往的問題是 5xx 難以重製,而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。

如果是隨機造成的問題就沒辦法重製,但如果是 client 的狀態造成的問題,就很有可能可以抓出來... 不是解決所有問題,但可以幫助解掉以前不太好解的狀況。