a11y

Pa11y Dashboard,

標題的 a11y 其實是 accessibility (親和力)的縮寫,現在英文世界似乎很大量的使用這個簡稱,今年的 JSConf EU 前陣子放出演講錄影,其中有一場是在講網路親和力的議題「YES, your site too can (and should) be accessible.」:

講者是 Laura Carvajal,在Financial Times工作,而這場演講就是他們改進 ft.com 網站親和力的過程和一些想法,我覺得精華在後半,前面是介紹自動化工具Pa11y,a11y 是 accessibility,至於首字母的 P,看 README 應該是 pal 的意思;他們把這個自動化工具整合進他們的開發流程,然後慢慢的修改,直到把回報的問題都修完,其實現在自動化工具已經很強了,連顏色對比度夠不夠都能算出來(瀏覽器的開發工具以後也會有相關資訊),不過要驗證親和力做的如何,還是有很大量的驗證其實是需要手動測試。

手動測試的部分他們是請了DAC(Digital Accessibility Centre) 來做,演講中還有一些測試者的測試影片,每位測試者都會先說他身體有怎樣的障礙,然後他邊測試會邊口述他在做什麼,遇到怎樣的問題,建議可以怎麼處理,感覺就是很專業的測試員。總之,在他們處理完所有 Pa11y 檢測到的問題後,才請 DAC 做親和力評估驗證,結果還是收到了一份兩百多頁的測試報告,回報了各種 ft.com 網站上的親和力問題,之後又花了幾個月的時間來處理這些問題,最後終於得到 DAC 的認證,這份認證資訊還蠻完整的,還說明了他們認證時網站的狀況,還有哪些問題待解決,甚至連可能會使用到但是還沒處理過親和力問題的同組織的網站(服務)都有列出來,另外在 ft.com 的親和力聲明也可以看到 DAC 的認證。

接著 Laura Carvajal 介紹到如何實際體會(參與)這些親和力問題,其中一個很經典的狀態就是只用鍵盤做所有的控制,他提供了一些強迫自己只能用鍵盤操控的方法,並且在這種狀態下工作,其它還有像是使用 Mac 的 VoiceOver 做為 ScreenReader、使用 Windows 的高對比模式等等,他建議可以實際自己去體驗看看的,甚至強迫自己使用一陣子,會對這些問題更有體會,除此之外,他還透過一些活動來讓其他公司內的人也來參與,像是模擬一個障礙者會面臨的環境,以他的例子來說是把網頁模糊化,模擬視力障礙的使用者狀態,然後在這個狀態下請人去完成一些任務,像是填一個表單,並且有提供些獎勵增加參與人數,記得他們是提供 Amazon Credit,這樣可以讓更多人體會到需要依靠輔具來上網的不便,長久下來也可以讓這些工作的推動更加順利。

這幾天我也試著裝起了Pa11y Dashboard開始做些檢測,看到的 Error 加上 Warning 數量真是有點驚人,再來慢慢處理吧...


Telegram Instant View

Telegram Instant View,

Telegram 前幾天發佈了 4.0,有幾個比較大的功能,包括了Video MessagePayment for Bots還有就是Instant View準備要開放給所有網頁使用了,Instant View 目的和 Facebook 的 Instant Article 以及 Google 的 AMP 一樣,都是為了提升使用者體驗,讓使用者能夠快的看到文章的內容,不過之前沒有開放,所以一直不知道背後的運作原理是怎樣,直到這次 4.0 發佈才得以一窺其原理,和 Instant Article 與 AMP 不一樣,不再是提供另一個新的版本,而是透過一種新的 template 語言來協助 Telegram service 把自己的網頁內容轉譯成 Instant Article 的內容(Instant View page object),不完全算是程式語言,裡面比較像是一些定義,加上用XPath來做文件內容的選取,蠻意外會用 XPath 的,還好我對 XPath 有點經驗,就花了一點時間研究了一下,也把自己 blog 的 tempalte 基本版做出來了:

?exists:  //article/div[@id="comments"]

author:  "othree"
channel: "@othree"

body:     //article
title:    $body//h3[1]

cover: $body/section[@itemprop="articleBody"]/p[1]/a[@itemprop="image"]/img

published_date: $body/header/time[@itemprop="datePublished dateModified"]/@datetime

@remove: //article/header
@remove: //article/footer
@remove: //article/div[@id="comments"]
@remove: //noscript
@remove: //a[has-class("dsq-brlink")]

語法還算蠻好理解的,官方也提供了幾個有完整註解的範例,仔細一看似乎之前其實也只有 medium 是非官方有支援的網站,也因為這個實做方式,對不同的網站就要有不同的 template 來處理,所以官方辦了個競賽,搶先替清單上的網站做出可用的 template 就會有獎金,目前個人網站雖然已經可以在官方的 editor 做 template、驗證並發測試連結,不過還要等 domain 被加進白名單後才會真的啟用,目前這個關卡還沒開放就是。

其實我是比較喜歡這種實做方式的,不用為了增加支援一個新的網路服務就多做一個版本,不會影響原本的網頁原始碼,不會讓<head>越來越肥大,當然缺點就是網站改版,HTML 結構有變化的話就要跟著修改 template,不過我是認為這個實做方法對於網路生態是比較好一些的。


MovableType and CommonMark

Typora

我這邊用的 blog 系統是MovableType不是新聞了,然後也因為用 MovableType 我一直都只能用最初版的 markdown 引擎,沒錯,就是 Daring Fireball 作者 John Gruber 的那一版,這個版本其實已經可以滿足我大部分的需求了,不過當我想要用Typora寫文章的時候,就遇到問題了,Typora 在輸出成 Markdown 文件時,code block 只支援三個 ``` 包起來的Fenced Code Block,而不支援Indented Code Block,剛好初版的 Markdown 格式只有 Indented Code Block,兩者其實要比的話,我是比較喜歡 Indented Code Block 的,比較符合 Markdown 的 sense,不過用 Fenced Code Block 有個優點是可以指定程式碼的語言,也因此才能夠有 syntax highlight 的效果。

總之,因為這個原因,用 Typora 寫技術文章對我來說就很不方便,一直以來都有想解決這個問題,前兩天還去 Typora 發 issue 說希望他們可以支援 Indented Code Block,結果發完沒多久,躺在床上快要睡覺的時候突然想到,CommonMark 這麼多語言有實做,搞不好有 Perl 的啊,結果快速搜尋了一下,還真的有一個perl-commonmark,橋接 Perl 和cmark,也有發佈到 CPAN 上,當下心裡就盤算著,隔天起來要來把它接到 MovableType 去看看。

結果隔天實做起來是沒花我太多時間,雖然對 Perl 不熟,但是可以直接拿初版 Markdown.pl 來修改,原本的 Markdown.pl 這個檔案裡面實際上自己是一個 Markdown 的 Perl Package,同時也可以作為 MovableType 的 plugin script,我只需要把 plugin script 的部分留下,然後把最後做轉換的 function 換掉就好了,當然系統要裝好 cmark 和 Perl 的 CommonMark,cmark 應該很多環境都有了,我在 archlinux 上是直接用 pacman 裝:

pacman -S cmark

然後 CommonMark 是用 CPAN 裝,本來要用 cpanminus 的不知道為何用它會抓不到 package:

sudo CPAN CommonMark

我的 nginx 跑 CGI 時用的 perl 不是系統預設位置的,所以 CPAN 執行檔的路徑我是特別指定給他的,這樣 MovableType 執行的時候才找的到 CommonMark Module,實際上沒花多少功夫,我就把 MovableType 和 CommonMark 串起來了,當下心情真的是非常難以言喻,一來是這個問題其實存在已經許久了,二是我竟然把第一個支援 Markdown 的部落格系統接上 2017 年最新的 CommonMark 實做,雖然現在應該是也幫不到什麼人了。不過沒高興多久,就發現在 UTF-8 字元似乎有些狀況,有中文的文章會爛掉,或是 Dashboard 那頁的文字會變亂碼,後來為了這個問題又弄了好幾個小時,推測問題應該是因為 cmark 那邊回來的字串已經失去編碼的 metadata,所以在做 summary 切文字的時候,就會出現切錯地方的狀況,花了很多時間交叉比對和測試,最後的結果只是用 Perl 的 Encoding 把 cmark 傳回來的字串重新 encode 過而已,其實很簡單。除此之外,我其實還有試著想接看看cmark-gfm,因為它還多支援了 Table,不過幾次測試都不太順利,就沒繼續嘗試下去了。

目前的成果放在 GitHub 上,取名叫MT-CommonMark,附上簡單的安裝說明,暫時是沒打算發去 movabletype.org 那邊。

做好之後 MT-CommonMark 之後,我就開始在部落格上測試程式碼的 syntax highlight了,研究一陣子之後選擇的是prismjs,選擇它的原因很多,不過有兩個是比較主要的:

  • 作者有Lea Verou
  • 支援的 class name 格式剛好和 cmark 輸出的一樣

結果兩者也很順利的搭配起來,中間就沒有再遇到什麼問題了。


GitHub Flavored Markdown 標準規範

Github Markdown Cheat Sheet

前陣子看到 DK提到GitHub 的 Markdown:GitHub Flavored Markdown發表正式的 spec了,當時有大概看了一下內容,不過昨天才有空寫出來(然後今天也看到碼天狗有提到這件事),基本上這份spec是基於CommonMark的,只是多了一些語法,包括:

  • 刪除線
  • 表格
  • 待辦清單
  • 自動連結(包括網址和 email)
  • Raw HTML 黑名單:
    • <title>
    • <textarea>
    • <style>
    • <xmp>
    • <iframe>
    • <noembed>
    • <noframes>
    • <script>
    • <plaintext>

新增的部分都有很顯眼的標註,其中 Raw HTML 黑名單的 HTML 標籤的<都會被轉成 entity,基本上看起來是安全性考量,不過不太確定為何有些很老的標籤出現,感覺上和安全性比較沒關係。另外我還注意到emojireference link沒包含在這份 spec 內,emoji 或許是因為實做上的問題,轉成 unicode 字元相容性不好,要用 img 會有不少相依性問題,而 reference link 大概是因這是比較針對 GitHub 網站的特性。

GitHub 轉換 Markdown 引擎的過程也有在文中說明,這次 Markdown 引擎是從Sundown(更早是 Ruby 實做的redcarpet的樣子)改成cmark,當然為了這些新語法,他們 fork 了自己的版本出來,然後在真的套上 GitHub 本站前,有先做過測試,結果發現有 1% 的文件(所有的 Markdown 文件,包括 user comment、issue...etc)會受到影響,而且判斷方法不是單純 diff 輸出結果,而是 diff 正規化過的 HTML 文件樹,不過即使只有 1% 的文件,那也是很大量,後來他們又更仔細分析,發現會受影響的幾乎都是 issue、user comment 之類的內容,是存放在 GitHub 資料庫內的,而不是 repository 內的文件,所以他們可以直接修改,如果是 repository 內的文件,因為要看 sha1 hash,所以是改不了的,後來他們魔改 Sundown,讓它吃舊文件然後吐出符合新 spec 的 Markdown 文件,接著跑了幾天把全部需要修改的舊文件(1%)都轉完,所以現在除了少數文件外,剩下的文件都是符合 GFM spec 的文件了。


GitHub 提供專案授權簡介與概要

Do What The F*ck You Want To Public License,

大概上週看到有人在 Twitter 講到 GitHub 現在會在專案上顯示該專案所使用授權條款的摘要,長的像是上面那樣,官方也有發表公告,其實這個修改是結合之前的授權偵測Choose a License

Choose a License 也是一個 GitHub 的附加服務,用來協助使用者挑選適合的授權條款,現在在 GitHub 建立新的專案時,可以順便初始化專案,包括建立 README、產生.gitignore和挑選要使用的授權條款:

Initialize Project

授權條款旁邊的 i 點下去其實就會送到 Choose a License 網站去了(不過兩邊沒有連動接起來就是),Choose a License 網站則針對每種條款都一份重點摘要,分為 Permissions、Conditions 和 Limitations 三個區塊,分別條列出該條款可以做什麼(例如商業使用)、有什麼條件(例如需要也使用相同條款授權)和條款的限制(例如免責),而現在 GitHub 上顯示的條款摘要其實就是這邊的資訊搬過來的:

Choose a License

Choose a License 網站其實有很多授權條款的整理,而不是只有常見的幾種,可以看appendix頁面有完整清單,可惜裡面沒有Vim License,另外特別想說的是 GitHub 自己(應該沒錯)提供的Unlincense,相似於創作領域的CC0,就類似丟到 Public Domain 的意思,不過保留了免責條款,講到免責聲明,就還要順便提一下WTFPL,它其實也是超自由的 License,差別就是連免責聲明都沒,其實是更加接近丟到 Public Domain 吧?

最後想說的是 GitHub 用來判斷專案使用的授權,用的是licensee這個 Ruby Gem,看起來完全就是為了做這些事情寫的,我看好像也沒其他類似功能的專案,作者 Ben Balter 其實也是 GitHub 員工。


Guetzli: A New Open Source JPEG Encoder

Guetzli

今天一早起來就看到 Google發表的新的 JPEG 壓縮程式,叫 Guetzli(一種瑞士餅乾),這是 Google 繼ZopfliBrotli之後,算是第三個比較容易被大家廣為使用的新的節省網路流量的工具,這次主要針對 JPEG 圖片格式,和之前 Mozilla 的mozjpeg的作法一樣,保持目前 JPEG decoder 的相容性,然後看能加強 JPEG 圖檔到什麼程度,我稍微測試了一下,結果還不錯,目前還沒有 homebrew formula,如果要自己 build 的可以參考這篇,基本上就是用 bazel 來編譯,然後可能會需要先裝 libpng 和 gflags,這兩個可以用 homebrew 安裝:

brew install libpng gflags

然後裝bazel

brew install bazel

然後到專案目錄下執行編譯指令:

bazel build -c opt //:guetzli

結果就會把執行檔放到bazel-bin/guetzli這位置,就可以拿來用了,不過其實官方 GitHub repo 上的release那邊就有編譯好的版本,抓下來用 Terminal 執行chmod +x也可以用(我是自己丟到/usr/local/bin/裡面),指令很簡單,可以加上--quality,預設是 95,不過最小只能 84,設更小的值會跟你說,真的想要的話自己去改原始碼...

速度就如大家所說的,和其它工具比起來真的慢很多,感覺是有一些 recursive 找最佳解的過程,輸出的結果我覺得最讓人印象深刻的是對於純色色塊的處理,也比 mozjpeg 好上不少,輸出檔案的大小不一定會是最小的,不過品質好很多,差異是達到我可以放棄這點容量差距,而寧願要這畫質改進,然後就是 Quality 100 可能會體積暴漲,我隨便測試了幾張圖片,看起來設到 90 品質就蠻不錯的,看來目前通行的圖片最佳化工具又要有一輪更新了。


網路發佈資料之最佳實踐

Data on the Web Best Practices

前幾天 W3C 發佈了這份文件Data on the Web Best Practices(DWBP),內容是關於在網路上發佈資料時的最佳實踐(公開或非公開的都適用),讓我想到了之前的 g0v summit 羅佩琪分享提到的一個重點,開放是有成本的,當時演講的影片:

稍微看過這份文件後,覺得之前確實蠻缺乏這份整理好的文件,每點看了就都覺得,確實是應該要這樣的,不過沒有這種整理好的 checklist 其實真的要做的時候還蠻容易漏東漏西的,然後就是,每一點都是成本啊!!

整份文件還蠻有翻譯的價值的,比較不像是 HTML Spec 會常常更新,不過我自然沒這麼多時間可以翻譯,所以就先把重點標題翻起來放,以後有人要開始就先有個基礎了,DWBP 整份文件有 35 點 Best Practice,每一點都有標題、簡述、原因、預期結果、可能實做方法、如何測試、證據、好處、範例等內容,其中好處的部分是分成八種:

  • Comprehension,人類容易理解理解
  • Processability,可程式自動處理
  • Discoverability,可讓程式自動發現
  • Reuse,容易重複使用
  • Trust,可靠
  • Linkability,可連結
  • Access,容易存取
  • Interoperability,容易互動(發佈者和使用者之間)

我只翻譯了其中的標題和簡述,順便附上每一點的好處(上面的八種好處),以下就是這 35 點 Best Practice:

閱讀「網路發佈資料之最佳實踐」全文

Safari 10 for Developer

Safari 10 跟著 macOS 一起出來了,這次更新了不少東西(對於網頁開發者來說),Apple 也依舊放了一份文件在他們的 Developer Library 裡面,以下列出我覺得比較有趣的:

CSP 2.0

CSP 2.0 和之前的版本相比,最主要是多了非常多可以控制的權限,也有幾個名稱有改掉,不過基本上格式是相容的。

Shadow DOM

Shadow DOM 1.0 標準,這也讓 Web Component 的理想又往前賣進一步了。

ES 6

號稱支援度 100%,看起來是依據ECMAScript compatable table的,不過在 module 的面前,還沒有真的 100% 的啊,另外主流瀏覽器其實支援度都蠻高了,之前 Edge 還放話說領先的,沒想到現在就已經被 Safari 10 和 Chrome 超過了,而 Chrome 看來也之差 tail call 而已,接下來應該又要開始效能比拼了吧。

Inline and Auto Video Playback in iOS

這也是等很久的功能,之前就有先開放靜音影片能直接在 iOS Safari 上自動播放,主要的考量是,gif 和 mp4 相比,還是 gif 比較吃資源啊。

ES Internationalization

ECMA-402 支援,這也是希望快點普及的東西啊,不然數字、日期什麼的搞本地化實在很麻煩。

WOFF 2.0 Support

令人意外的有點慢,不過還算很有誠意的把很新的CSS Font Loading Module Level 3的 API 做好了。

#RRGGBBAA

新的 CSS color 格式,也是前陣子才 propose 出來而已,這樣以後就可以讓 CSS 裡的顏色格式統一點了。

Right-to-Left Language Support

主要是 RTL 頁面 scrollbar 的位置終於會換邊了。

Media Query for Wide Color Gamut Support

廣色域的 CSS media query,主要是因為最新的 iMac 和 iPhone 7 都有支援 P3 色域了。

WebDriver Support

主流瀏覽器最後一個支援的...

Apple Pay for the Web

這真的蠻兇狠的,不過 Google 也有在 Android 做類似的就是了。

大概就這些了,其實也列出超過一半的項目了,Safari 這種更新頻率其實比起其它幾家來說吃虧不少,不過還是一直有跟上最新進度,其實也蠻厲害的,更何況現在 Google 都把人拉到 Blink 去,有回到 Webkit 的貢獻似乎比例上不高。


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

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


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 目前實做的似乎就是這個協定更早版本的草案


此類別所有文章