Modern HTML Email Development

今天在 Modern Web 分享的主題

其實最主要是想介紹MJML這個工具,不過最後介紹的篇幅有些不夠,有些可惜,話說今天設備也有些狀況,一是投影機解析度和預期的不一樣,二是無線麥克風聲音會延遲,對於講者來說還蠻干擾的,最後時間還剩的比預期多,覺得愧疚啊。

最後附上這次介紹的一些資源的連結,方便取用:


JSON Web Token

大丸百貨

之前的JSON Universe那篇文章在寫的時候,還沒發現到有這東西,直到上個月才發現到JSON Web Token(JWT) 這個標準,研究過後覺得要單獨介紹一下,不過由於相關的標準有好幾個,花了些時間才搞清楚各個標準之間的關係;這一系列標準是由JOSE(JSON Object Signing and Encryption) Working Group所制訂的 RFC 標準,目前包括了:

共五個 RFC 標準,事實上,JSON Web Token 是要最後談到的;這一系列標準的目的是提供一個標準的協定,用在傳輸 JSON 資料時提供可靠性(簽章、signature)和安全性(加密、encryption),眼尖的人可能發現了,怎麼沒有 JOSE 的文件呢?事實上是真的沒有,而且也沒官方文件清楚解釋 JOSE 到底是什麼,最常看到的詞就是 JOSE Header 了,思考許久後才理解,JOSE 其實包括了兩種格式,分別是 JSON Web Signature(JWS) 和 JSON Web Encryption(JWE),JWS 只是加上驗證用的簽章,其實內容是明碼的,JWE 才是真的有把傳輸的資料加密過,至於簽章和加密用的演算法則是用 JWA 格式來紀錄,然後需要用到的 key,例如用非對稱加密保護加密內容的 key 給收信端,這時則是用 JWK 格式來記錄要使用的 public key,而這些資訊就是 JOSE Header 的內容了,JWK 和 JWA 都是很簡單的格式,基本上就是一個物件,然後有定義好的屬性:

{
  "kty":"EC",
  "crv":"P-256",
  "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
  "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
  "kid":"Public key used in JWS spec Appendix A.3 example"
}

例如這個 JWK 文件範例中的kty代表的是 Key Type;crvxy則是橢圓曲線加密(ECC)類演算法會用到的參數;kid則是自訂的 Key ID,用來在一堆 JWK 當中尋找所要的 key 使用;其它還有像是 X.509 憑證驗證會需要的資訊,各種加密演算法會用到的 Initialization Vector、Salt 等,都有定義好的屬性名稱。

JWS 和 JWK 就比較複雜些了,以 JWS 來說,你會先有要傳輸的資料 payload,然後一組 meta data,又稱為 JOSE Header,內容基本上就是 JWA + JWK + 一些基本的屬性,像是ctytyp

{
  "typ":"JWT",
  "alg":"HS256"
}

這就是一個最簡單的 JOSE Header,它說明傳輸的資料內容和簽名用的 HMAC 演算法,然後這個 JOSE Header 和 payload 要分別轉成base64url編碼,其實和 base64 沒差很多,就先把 JSON String 轉成 base64 encoding string 後,把 padding 的=都拿掉,然後+-取代,/_取代。例如ab?ab這個 ASCII 字串,用 base64 encoding 就會變成:

YWI/YmE=

用 base64url 的話就變成:

YWI_YmE

然後現在我們有一個 JOSE Header 和一個要傳輸的 JSON payload,以 base64url 編碼呈現並且用.接起來:

BASE64URL(UTF8(JOSE Header)) || '.' || 
BASE64URL(JWS Payload))

接著把這個字串拿去用 JOSE Header 裡面指定的 HMAC 演算法搭配一組 key 來算出簽章(signature),至此我們就有了 JWS 三樣必須的元素了:

  • JOSE Header
  • Payload
  • Signature

JWS 文件中定義了兩種格式可以用來傳輸這三個元素,第一種是精簡格式(Compact Serialization Syntax),格式很簡單,就和上面算 signature 用的格式一樣,只是現在多加了 signature 在後面,一樣用 base64url 形式:

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)

長的會看起來像是:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

另外一種則是 JSON 格式(JSON Serialization Syntax):

{
  "payload":"eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9",
  "signatures":[
     {"protected":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9",
      "signature":"TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ"}]
}

這種形式其實是最完整的版本,還可以加上 public header (沒 signature 驗證)和多個 signature;另外也有 flatten 版,只能放一個 signature:

{
  "payload":"eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9",
  "protected":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9",
  "signature":"TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ"
}

雖然有 JSON 格式的 JWS,不過 精簡格式目前應該是最廣為通行的,一來是它資料量比較小,二是它比較方便在不同環境下傳輸使用,例如後面會提到的,放在 HTTP Header 內,如果沒有特殊需求要多個 signature,實在很沒有用 JSON 格式的需求。

最後,JWS 還有一個特殊的 case,就是它其實允許不加上簽章的,使用這組 JOSE Header:

{"alg":"none"}

然後 signature 是空字串,所以精簡格式的就會變成:

eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.

最後是.結尾。

JWE 和 JWS 的狀態其實也很像,只是三個元素變成五個,包括了:

  • JOSE Header
  • Encrypted Key
  • Initialization Vector
  • Ciphertext
  • Authentication Tag

其中 JOSE Header 和 JWS 的內容差不多,Encrypted Key 和 Initialization Vector(IV) 是加密時的輸入,這邊的 Encrypted Key 是一把加密過的 Key,被加密保護的 Key 又稱為 Content Encryption Key(CEK),是實際上用來加密保護內容時所使用的 Key,這把 CEK 和 IV 都是亂數產生的,那又有一個問題是,用什麼 Key 加密 CEK 來產生 Encrypted Key 呢?這邊建議的是用非對稱加密,拿收信方的 public key 來加密,當然 JOSE Header 裡面也可以塞進 x.509 的相關資訊用來確保 public key 的正確性;最後兩個,Ciphertext 和 Authentication Tag 則是加密的輸出,Authentication Tag 是 authentication encryption 會產生的,用來驗證內容正確性的資訊,就像是 JWS 的 signature 一樣用途,主要也是避免 Ciphertext 被用中間人攻擊替換掉,不過我還不太清楚如果可以偷到 key 偽造出 Ciphertext,是怎樣會沒法同時有另外一組 Authentication Tag 就是了。

然後一樣有精簡格式和 JSON 格式,精簡格式看起來就如下:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGeipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDbSv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaVmqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je81860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi6UklfCpIMfIjf7iGdXKHzg.48V1_ALb6US04U3b.5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6jiSdiwkIr3ajwQzaBtQD_A.XFBoMYUZodetZdvTiFvSkQ

注意找的話就可以發現四個.把資料切成五段。

最後終於要來介紹 JSON Web Token(JWT)了,JWT 是什麼呢,它其實就是一個 JOSE 的應用,一句話來說,就是使用 JWS 或 JWE 來做現在網路服務的身分認證協定中常見的 token(權杖)的傳遞。所以 JWT 其實就是規範了一組 JSON 資料的屬性(claim),和身分認證相關,然後要求這個 JSON 資料要用 JWS 或 JWE 來傳輸提供保護,這些預先定義好的屬性有:

  • iss, Issuer
  • sub, Subject
  • aud, Audience
  • exp, Expiration Time
  • nbf, Not Before
  • iat, Issued At
  • jti, JWT ID

都是非常 meta 的 token 屬性,這些名稱基本上是從OpenID Connect那邊來的,除了這些定義好的屬性之外,還可以加上其它自訂的資料,只是這些已經被定義且註冊好的名稱不能另做他用,OpenID Connect 也有不少個人資料的屬性已經註冊上 IANA 了,像是first_namecountry之類的 profile 資訊,有一種使用 JWT 的方法就是直接把個人 profile 存在客戶端,server 只要驗證簽名是否正確,這樣一個好處是 server 不用保存 session 資訊,減少很多資源的需求,實做起來其實複雜度也比較低。另外由於是用作 token 之用,自然也可以當成 OAuth 的 token 使用,這部分資訊在RFC-7523這份文件有說明,至於要如何使用 OAuth token 則是在RFC-6750有介紹,比較常見的是放在 HTTP Auth Header 裡面:

Authorization: Bearer eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.

之前鴨七也有整理過中文的說明,看起來比較輕鬆,而且說明很完整(不過我承認我沒有從頭看到尾)。

目前搜尋 JWT 一定會看到一個網站jwt.io,這個網站用淺顯易懂的方式來介紹JWT,把比較複雜的關係,像是 JWS、JWE 等等都隱藏起來幫助瞭解,還有一個線上除錯工具和不同語言的 library 整理,不過除錯工具只有支援 JWS,另外也有和一些其它類似標準做比較,還蠻值得看一看的,這個網站是由Auth0提供的,他們其實就是一家專門提供身分認證服務的公司,似乎都已經轉到使用 JWT 了,在 jwt.io 有提到他們似乎是把他用作 stateless 的 token 來用,我對這間公司之前印象是還不錯,一來是 API 文件看起來還蠻不錯的,另外有不少的開放原碼專案,當然有一些是串接他們家服務用的 library 啦。

PS. 對密碼學還沒很熟悉,有誤歡迎指正~


7 Bit Encoding and Email

最近工作上比較常接觸到 email 的東西,然後比較認真的看了 HTML email 信件的內容,以前我以為都要用 base64 編碼來處理,可是用 base64 來處理 HTML email 我一直覺得很不合理,一來大小會變 1.33 倍,二來整個 HTML 原始碼傳送時會變的幾乎無法辨識,收信軟體還要先解碼一次才可以 parse HTML,感覺完全不需要多此一舉,總之就是覺得為什麼要做這麼愚蠢的事情,明明看起來MIME就沒這樣限制,所以我應該可以這樣寫:

Content-Type: text/html; charset=utf-8

然後內文直接放 HTML 原始碼,可是不知道為什麼沒人這樣做,事實上也不 work;最近多看了一些郵件原始碼才發現其實還有個 Quoted-Printable encoding 也很常用,看起來比 Base64 的結果還要接近原始碼許多了,所以就研究了一下它到底是什麼格式。

Quoted-Printable encoding 的基本原理就是用=作為 escape 字元,然後可以把要轉換的字元轉成=字碼的形式,例如 Big5 中文的就要轉成=A7=DA,規範上要轉換的是除了可見(printable)ASCII字元以外的字元都要轉,而 ASCII 是個 7bit 編碼,字碼只有從 0 到 127 而已,而 email 要用 Quoted-Printable encoding 的主要原因其實就是為了讓文件內的每個字元編碼都維持在 7bit 編碼範圍內,現在大家常用的編碼像是 UTF-8 和以前常用的 Big5 等都是 8bit 編碼,兩者差別就在於每個傳輸的 byte 中有沒有使用到第 8 個 bit,轉成二進位的時候,7bit 系統編碼不會用到最左(higher-order)邊的那個 bit。

為什麼需要用 7bit 的文字編碼呢?主因是計算機和電信網路早期很多系統是只支援 7bit 編碼的,SMTP 的規範就直接要求 TCP 傳輸時,每個 byte 最左邊的 higher-order bit 要填 0:

The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.

當然這規範很落後時代,所以在MIME(Multipurpose Internet Mail Extensions)規範其實也有Content-Transfer-Encoding可以指定傳輸用的是什麼編碼:

Content-Transfer-Encoding: 8bit

不過為了相容舊系統,還是很少真的這樣使用的信件在傳遞,因為要是傳到了 7bit 系統,小則亂碼、大則程式當機。不過這就帶出另外一個問題了,難道 7bit 系統只能傳輸 ASCII 字集嗎?因為我還蠻常看到日文的純文字郵件,就去找了一些來看看,結果發現到有的是用ISO-2022-JP,而且是使用 7bit 的傳輸:

Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

信件內容的文字也都很正確,沒有亂碼:

iso-2022-jp

於是就看一下ISO-2022的介紹,發現原來是個很早就有的 7bit 編碼方法,後來根據這方法有訂出了 CN、JP、KR 等語言的編碼,不過比較通行的看來只有 ISO-2022-JP,然後我也找到 HTML email 用 ISO-2022-JP 的:

ISO-2022-JP

看起來就像是我理想中的 HTML email 原始碼啊,所以問題的癥結其實是,大家為了相容於舊系統,所以都用 7bit 傳輸,要 7bit safe 的 encoding 選擇有限,除了比較通行的 ISO-2022-JP 可以給日文用、字元太少只能給英文用的 ASCII 之外,其它語言就只能用 Base64 encoding 和 Quoted-Printable encoding 了,所以事實上其它 7bit 編碼的內容,也是可以直接透過 SMTP 協定來傳輸的,只是要看收信端的軟體能不能支援解碼,像是已經不太有人用的UTF-7就是 7bit 的 unicode 編碼。

最後,就是假設我們已經不用擔心老舊系統的時候,其實只要這樣寫在 MIME header 裡就可以直接傳 UTF-8 的 HTML source,不用再經過任何編碼處理了:

Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

不過距離這一步不知道還有多遠就是了。


HKOSCON 2016

HKOSCON 2016

今年有幸可以參與香港的 Open Source Conference,這趟還承蒙 Mozilla 贊助交通費用,另外因為是講者的關係,住宿的部分則是 HKOSCON 幫忙。其實至少去年就想去了,不過去年因為事情比較多就放棄了,今年還乾脆的投稿分享,不過因為工作的關係,只有參加週六的議程,週五的部分就沒參加到了,聽的議程如下:

  • 回顧台灣自由開源軟體發展 by Jim Huang
  • Interactive Dashboard Development with Plotly by Mart van de Ven
  • Fluentd: Unified Logging Layer by Masahiro Nakagawa by Andy Shu
  • Optimizing Chinese Webfont & Typography by Andy Shu
  • Mozilla Eir - Bring medical devices into the world of webby Kevin Hu
  • From Open Source to Open Media by Hsin-Chan Chien
  • My Mozilla Contributing Journey by Irvin Chen

第一場就是 Jserv 介紹台灣以前的自由開源軟體的發展,我到會場的時候已經開始講的,介紹的比較是早期的發展,是我有參與到這個圈子前的時期,對我來說大部分都是,照我印象比在台灣之前說到的還要詳細些,不過我的聽幾次 Jserv 的分享感覺下來,就是大概進入 COSCUP 開始辦之後,參與發展在地化的自由開源軟體的人卻越來越少,當然我自己也是沒參與啦,其實曾經我本來要幫忙新酷音的網站(目前是WM維護),不過因為一些奇妙的原因我就沒幫上了。

HKOSCON 2016

Plotly則是一個 plot library,我是沒很注意聽,有興趣可以自己研究一下優缺點,目前這市場似乎有點飽和,可能等真的有需求時再來研究吧。

Fluentd是最近蠻多人會用的 log 收集中間人,我目前工作上雖然沒有直接接觸,到是有間接使用到,不過我到來聽這場的這時候才知道,原來作者是日本人,不得不說有點意外,來講的是 Masahiro Nakagawa,是目前專案上排第二的開發者。

Optimizing Chinese Webfont & Typography 這場的重點其實就是動態組字形技術,以前台灣這邊也有人在弄,有商業化的就是justfont了吧,不過沒想到這技術現在也有開源專案提供了,這場 Andy 介紹的是font-spider這個專案,有興趣的可以自己玩玩看。PS: 我覺得 justfont 不斷拓展方向的策略還蠻正確的,不然單靠 Webfont 就蠻危險的。

Mozilla Eir則是第一場 Mozilla 相關的主題,主要是介紹 Mozilla 參與醫療器材平台發展的專案,目前還在蠻初期的,個人感覺還在規劃和討論的階段,所以還沒有實際的成果或是可以 demo 的東西。

HKOSCON 2016

From Open Source to Open Media 則是 HC 從 OSDC 到現在報導者之間的歷程,聽完之後覺得經濟動能推升方案那支廣告,當時看覺得是什麼鬼,現在看覺得效用真的很大啊(?),然後就讓我想到 g0v 有一個推人入坑的方法,就是先弄一個糟糕的版本推上線,然後就會有人受不了出來修改。

HKOSCON 2016

HKOSCON 2016

My Mozilla Contributing Journey 這場則是Irvin自己從開始參與 Moztw 社群到現在一路的歷程,因為參與 Moztw 而有了什麼收穫等等,我印象中有這樣明確整理出因為參與開源社群而獲得的收穫的分享,好像是沒有,有興趣的話,他在 SITCON 夏令營還會再講一次,有興趣的或許...報名好像結束了就是。

除了上面聽的兩場和 Mozilla 相關的題目之外,還有一場我沒聽的是 Gary 的演講,題目是之前講過的 Fuzzy Test,不過是 2016 年版,Fuzzy Test 我覺得真的是自動化整合測試最後一關了,基本上就是把所有正常的操作都測試完之後,就來測個不正常的操作吧,那怎樣產生不正常的操作流程呢,就是可以用 Fuzzy 的方法來產生,不過他自己有說今年 Mozilla 在這邊的資源變少了;其實我覺得 Mozilla 最近方向實在是不太明確,我印象中的整個轉捩點大概是 Brendan Eich 下台開始,然後 Firefox OS 的市佔率也起不來,Firefox 的發展也越來越跟不上 Chrome,像是 e10s 就一直都還不太行,真的是蠻讓人擔心的,好在是短時間還不需要擔心資金問題的樣子。

然後還有一場間接相關的就是我的分享了,這個題目本來是有考慮投 COSCUP 的,後來還是投到 HKOSCON 這邊,也是我第一次嘗試用英文演講,可惜我練習不夠,講的實在不好,很多地方都覺得好像沒正確的講清楚,下次還有機會用英文演講的話應該還是會再試一次,希望下次練習更充分,表現正常些,不然就要上場前喝罐啤酒試試看了,根據我之前的試驗結果,好像喝過酒的情況下,講的會比較流暢XD。

除了演講外,還有一區有廠商攤位,還有一個 Job Board 版面可以給人貼徵才資訊,攤位的部分,IBM、VLC、Google、HKLUG﹑自由香港字型等是我比較有印象的,IBM 是介紹他們的 AI as Service 的服務,紀念品當中還有一些 for Dummies 系列叢書:

HKOSCON 2016

Google 不知道怎麼會願意來擺攤,沒跟他們聊聊,台灣 Google 好像還沒在社群擺過攤的樣子,如果有錯還請幫忙更正,不過總之我拿到 Chrome 貼紙了,這樣曾經的五大瀏覽器,Chrome、IE、Firefox、Opera 的紀念品我都有拿到過了,只差一個台灣實在很難碰到的 Apple 的 Safari 而已。

自由香港字型則是一群人要造屬於香港字的自由字型而聚集起來的社群,主因是因為香港漢字其實有一些字的寫法、筆畫和台灣日本的不一樣,例如下圖中間的「周」:

HKOSCON 2016

然後過去又沒有可以自由使用的字型可以用,所以開始了這個計畫,相信大家也都知道要造一套字型有多大難度,所以這社群有些成果出來真的是很厲害。

整個 HKOSCON 規模比台灣常參加的研討會還要小一些,不過參與的外國人比例感覺比較高,英文議程也多一些,相較來說是對外國會眾友善不少,當然我想英文在香港比較流通也是主因之一,在台灣要做到國際化的研討會實在不太容易,目前比較常見的問題包括:翻譯問題,雖然可以靠口譯解決,不過成本瞬間提升,光靠贊助很難,所以幾乎是要全商業化的形式才比較有可能,票價也會因此和國際接軌;入境問題,中國人要到台灣困難度很高(好像還有幾個國家要來也很困難,一時忘了),這也造成一些國際研討會亞洲場不考慮台灣的原因,這問題很難靠主辦解決就是。

最後還是要感謝 Mozilla 的贊助,還有 HKOSCON 大會和 Sammy Fung 的協助讓這趟行程可以很順利的完成,Sammy 也是 COSCUP 的常客,前陣子還開始了opensource.asia這個網站,收集亞洲相關的 Open Source 活動,大家有興趣可以 COSCUP 活動時找他聊聊。

HKOSCON 2016


Web Push

前兩天要研究一下 Chrome 接 GCM 的實做,發現到 Google 又出一個新的服務叫 Firebase,然後新的 cloud messaging 服務就叫Firebase Cloud Messaging(FCM),隨便看了一下 Google 官方的文件,結果發現有提到另外一個正在制訂中的Web Push Protocol,照文件的說法,FCM 也只是個過渡時期的方案,最終目標還是用這個 Web Push Protocol,於是我就研究了一下他的設計,發現設計的還蠻漂亮的。

整個 Web Push Protocol 的基本架構如下圖:

Web Push Protocol

User Agent(UA) 通常是行動端的應用程式、Application 則是自家服務的後台;整個流程首先是 UA 透過 HTTP/1.1 POST 去跟 Push Service 訂閱(第一條橫線 Subscribe),然後會拿到一個 subscription resource,可能長成:

https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG

另外還會拿到一個發訊息用的 push resource:

https://push.example.net/push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV

可以注意到兩個 resource 後面的 token 是不一樣的,兩者之間的 mapping 就是 Push Service 來負責;然後 UA 拿到這兩個網址後,發訊息用的 push resource 要交給自家服務的後台,也就是圖上第三條橫線 Distribute Push Resource,另外一個 subscription resource 則是要自己使用,UA 用 HTTP/2 打 GET 到 subscription resource,然後 push service 會把連線保持住不關掉,這就是圖上的第二條橫線 Monitor;自家服務後台的要送訊息的時候,就打 POST 去 push resource,也就是第四條橫線,從 Application 到 Push Service 間的 Push Message,push service 收到這個訊息時,就利用 HTTP/2 的 Server Push 機制主動傳送訊息,最後這個動作就是第五條橫線的 Push Message 了。

就這樣很漂亮的用 HTTP/1.1 + HTTP/2 把一個基本的 Cloud Message Service 的協定建構起來,而除了這最基本的訊息傳遞外,這份文件還有定義像是訊息重要度、訊息回條、群組訊息等等的方法,設計都還蠻漂亮的,安全性的部分則是限制走 HTTPS over TLS,還有 operation 相關的說明,像是實際上要跑起這個服務,需要大量的 TCP connection 等等(因為都走 HTTP 了),有興趣的可以加減看一下。

補充:Firefox 目前實做的似乎就是這個協定更早版本的草案


➡ 看看其它文章