Firefox 成為第一個預設啟用 HTTP/2 的主流瀏覽器

Firefox 36 的 Release Notes 內宣佈預設啟用 HTTP/2

Support for the full HTTP/2 protocol. HTTP/2 enables a faster, more scalable, and more responsive web.

另外 Firefox 36 也拔除 RC4

No longer accept insecure RC4 ciphers whenever possible

接下來應該是 Google Chrome 預設啟用,以及 nginx 的 server implementation...

Google Chrome 將會用 HTTP/2 取代 SPDY

Google Chrome 將會在接下來幾個星期的 40 版支援 HTTP/2 (現在已經是 40 版了,所以照這個說法應該是 41 一定會有?),並且在 2016 年拿掉對 SPDY 的支援:「Hello HTTP/2, Goodbye SPDY」。

接下來又是大量的 migrate 了:

We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.

在「Implementations」這邊可以看到 HTTP/2 支援的程度,包括了 client 與 server 的部份。

Google 提議將 Chrome 對 HTTP 的連線標示成「不安全」icon

在「Google Proposes Marking ‘HTTP’ as Insecure in 2015」這邊看到 Google 提議將 Chrome 對 HTTP 連線標示成「不安全」:「Marking HTTP As Non-Secure」。

其中一個提案是設定三個時間 (T1、T2、T3),逐步改變對 HTTP 的標示:

T0 (now): Non-secure origins unmarked
T1: Non-secure origins marked as Dubious
T2: Non-secure origins marked as Non-secure
T3: Secure origins unmarked

不過這是好提案嗎?CA 機制並不完美,這樣硬推是對的方向嗎?

要瀏覽器不要送出 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 標準 (還在制定),可以來定期追進度...

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞,目前的標準還是 draft:「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP:(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的:「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽,這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

Mozilla 的 wiki 上面可以看到對應的條目:「SecurityEngineering/Public Key Pinning」,目前 Firefox 的版本是 31,也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台,以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com,另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。

文章裡有提到好處:

Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒,預設值是 60 秒。

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/1.1 的更新

HTTP/1.1 源自十五年前 (1999 年 6 月) 所發佈的 RFC 2616,而十五年後被翻新了。

可以在 RFC 2616 的狀態資訊上看到「Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235」,把本來的 RFC 2616 拆開成幾份文件:

在「HTTP/1.1 just got a major update.」這篇文章裡面整理了一些改變,大多數都是相容於現在的使用習慣,另外把一些過時的預設行為拿掉。(像是預設 charset 為 ISO-8859-1)

找機會來重頭翻一下,以後就不是翻 RFC 2616 了...

在 Flash 上播 HLS...

靠的是「Apple’s HTTP Live Streaming (HLS) in Flash !」這篇「2014/02/12 的 comment」解的 (不是原文內的方法)。

專案在 GitHub 上:「HLSProvider is a Flash/AS3 plugin that plays back HLS streams」。

使用方式與範例可以在「HLSprovider/test/flowplayer at master · mangui/HLSprovider」這邊翻到,直接看 index.html,並且把 swf 檔弄出來就可以動了。

不過實際測試發現 buffer 的部份好像處理的不是很好... 但至少有東西可以用了 :o

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).

所以就大膽用吧...