nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

Mozilla 的提案「HTTP Immutable Responses」

狀態已經是 Category: Standards Track 了,RFC 8246 的「HTTP Immutable Responses」:

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

Cache-Control 介紹了 immutable,像是這樣:

Cache-Control: max-age=31536000, immutable

依照 MDN 上的資料 (Cache-Control - HTTP | MDN),目前只有 EdgeFirefox 支援,不過既然成為標準了,後續其他瀏覽器應該都會支援 (吧):

Google 的 www.google.com 要上 HSTS 了

Google 宣佈 www.google.com 要上 HSTS 了:「Bringing HSTS to www.google.com」。

雖然都已經使用 EFFHTTPS Everywhere 在跑確保 HTTPS,但這個進展還是很重要,可以讓一般使用者受到保護...

Google 的切換計畫是會逐步增加 HSTS 的 max-age,確保中間出問題時造成的衝擊。一開始只會設一天,然後會逐步增加,最後增加到一年:

In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We've initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out. By increasing the max-age, however, we reduce the likelihood that an initial request to www.google.com happens over HTTP. Over the next few months, we will ramp up the max-age of the header to at least one year.

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o

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 在愚人節玩笑中造成的安全問題...

Google 在愚人節時拿出養很久不知道做什麼的 domain 出來用:「https://com.google/」,但也因此造成了安全性問題:「Google’s April Fool’s prank inadvertently broke their security」。

問題在於正常的 Google 頁面有這個 HTTP header 可以避免 iframe (以及 clickjacking):

X-Frame-Options: SAMEORIGIN

但在加上 igu=2 的參數後不會有這個 HTTP header。雖然現在已經失效了,但當天也被 Netcraft 通報 XD

要瀏覽器不要送出 Referrer 的 Referrer Policy

在讀「The No CAPTCHA problem」這篇的時候看到的:「Referrer Policy」。

<meta name="referrer" content="never">

目前正式版本的瀏覽器中,只有 Google Chrome 有支援,而其他瀏覽器正在開發,像是 Firefox 上個月才進 trunk:「Bug 704320 - Implement <meta name="referrer">」,預定在 36 版才會納入 (目前是 34)。

還蠻新的 HTML5 標準 (還在制定),可以來定期追進度...

Bitcoin 電子錢包的初始化加速

因為從以前到現在的歷史記錄都被累積起來,Bitcoin 電子錢包初始化所需要的時間變得很長,所以就有不少方法想要改善。

在「Bitcoin Blockchain Initial Sync Time Dramatically Reduced By Headers-First Sync」這篇文章裡面提到了一些事情。

目前的歷史記錄大約是 22GB,文章裡說平均是兩天可以跑完 (我自己是跑了五天...),但另外一個方法則是可以透過「[ANN] Bitcoin blockchain data torrent」這邊提供的 BitTorrent 方式下載記錄 import 進去,這樣就有機會縮短到 4 小時。

另外被提出來的方案是減少傳輸量先確認。而且這個方法已經被 merge 進官方的 client 了:「Headers-first synchronization」,過陣子來測看看速度如何...

Amazon CloudFront 的新增功能

Amazon CloudFront 新增了 Whitelist Header 的功能:「Deliver Custom Content With CloudFront」。

如同在 post 裡說明的:

If you choose the Whitelist option, each header that you add to the list becomes part of the cache key for the URLs associated with the distribution.

有點像是 HTTP 協定裡 Vary 想要解決的問題,只是做在 CDN 這端。這個功能蠻多 CDN 都有,AWS 總算補上了...

這次除了可以針對 custom HTTP header 處理外,CloudFront 還做了不少事情:

  • Mobile Device Detection
  • Geo-Targeting
  • Multi-Site Hosting
  • Protocol Detection
  • CORS (Cross Origin Resource Sharing)

前兩項還蠻有意義的,這代表會有人幫你更新資料。而 CloudFront 總算是支援 CORS 了...

HTTP Header 裡的 Location 使用相對路徑...

HTTP Response Header 的 Location (俗稱「轉址」) 被用在不少地方,剛好今天被 ccn 戳到相關的問題...

在維基百科的「HTTP location」條目裡面有說明 HTTP/1.1 的規範裡要求必須是 absolute URI:

Location       = "Location" ":" absoluteURI

但實務上,目前市場上常見的瀏覽器都支援相對路徑。而且在 HTTP/1.1 修正版 (目前還在 draft) 裡被修正成:

Location = URI-reference

並且說明 relative 時的判定方式:

The field value consists of a single URI-reference. When it has theform of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).

所以就大膽用吧...