User-Agent 的淘汰提案

看到廢除更新 User-Agent 字串的提案:「Intent to Deprecate and Freeze: The User-Agent string」。

一方面是 User-Agent 裡面太多沒用的假資料 (像是每一家都是 Mozilla),另外 User-Agent 會帶出一些隱私問題 (辨識資訊)。

目前的提案是希望改用 User-Agent Client Hints (UA-CH) 取代 User-Agent 的功能,把預定義好的東西透過對應的 HTTP header 傳遞。

Chromium 的計畫是在 M81 (stable 版預定在 2020 年三月中釋出) 先 deprecate navigator.userAgent,所以有存取時 web console 上會出現警告。而 M83 (2020 年六月初) 則是不再更動 user agent 字串 (鎖住)。到了 M85 (2020 年九月中) 則是統一 desktop 的 user agent 字串,並且盡可能統一 mobile 上的字串。

另外裡面也有整理了其他瀏覽器的意願:

Edge: Public support

Firefox: Public support for freezing the UA string - “freezing the User Agent string without any client hints—seems worth-prototyping”

Safari: Shipped to some extent. Safari has attempted to completely freeze the UA string in the past, without providing an alternative mechanism. That got a lot of pushback, which resulted in somewhat reverting that decision. Nowadays, their UA string seems frozen, other than updates to the OS version and the browser major version.

雖然不是完全都同意,但看起來應該有機會在今年陸陸續續搞定...

超快速的 Base64 encoding/decoding 實做

看到「Base64 encoding and decoding at almost the speed of a memory copy」這個,可以超級快速編解碼 Base64 的資料。

實做上是透過 IntelAVX-512 加速,在資料夠大的情況下 (超過 L1 cache 的大小),可以達到接近字串複製的速度 (這邊提到的 memcpy()):

We show how we can encode and decode base64 data at nearly the speed of a memory copy (memcpy) on recent Intel processors, as long as the data does not fit in the first-level (L1) cache. We use the SIMD (Single Instruction Multiple Data) instruction set AVX-512 available on commodity processors. Our implementation generates several times fewer instructions than previous SIMD-accelerated base64 codecs.

不過這樣 AMD 暫時要哭哭...

JSON Canonicalization

這篇是講 JSON object 上的簽名,但實際上就是在討論 JSON Canonicalization 的前因後果:「How (not) to sign a JSON object」。

在處理 JSON 資料時,「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題,其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative,這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後,你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah,總是有人愛在某種資料格式上面疊上簽名),也就是「XML Signature」這個方式。

在 XML 這邊不幸的是,還不少標準選用 XML Signature,像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO,而需要接 SAML...

回到原來的 JSON Canonicalization,可以馬上想到的變化包括了空白與 object 裡 key 的順序,也就是這兩個:

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是,還有 Unicode 來一起亂,也就是下面這個跟上面有相同的意思:

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的,如果你因為複雜而決定用 library 來做,那也代表 library 必須面對這些複雜的情境,未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

把 HTML 資料都塞到 URL 裡的服務

如標題說的,專案叫做「URL Pages」,是一個把 HTML 的原始碼都放到 url string 裡的服務。服務本身可以在 http://jstrieb.github.io/urlpages 這邊使用。

現在網路上有很多地方可以塞 demo page (像是 GitHub 自己提供的 GitHub Pages),這個方式需要依賴 JavaScript 提供各種轉換機制,應該會有不少 side-effect bug,看起來會有不少技術瓶頸,就當作是個實驗性質的專案來看,真的需要放 demo page 的還是可以隨便找空間放比較簡單,像是前面提到的 GitHub Pages 其實可以直接在 GitHub 的網頁上操作...

在 DOM 操作時的 insertAdjacentElement

看到「Why I'm still using jQuery in 2019」這篇,裡面提到了 jQuery 很多操作上相較於 vanilla javascript 簡單很多,其中一個例子提到了 DOM 操作的 insertAdjacentElement()

el.insertAdjacentElement('afterend', other) undoubtedly works, but $(el).after(other) is actually palatable.

其實我不知道 insertAdjacentElement() 這個功能,我知道的操作都是透過 parentElementfirstChild 在移動位置,然後用 appendChild()insertBefore() 放進去。

跑去 MDN 上查了「Element.insertAdjacentElement() - Web APIs | MDN」後才發現有這個好用的東西:

targetElement.insertAdjacentElement(position, element);

position 的四個變化減少了以前組積木組多了會頭暈的情況。

接下來是研究支援度的問題,才發現可能是因為 Firefox 一直到 48 才支援 (從「Firefox version history」可以看到 48 是 2016 年八月釋出),所以網路上大多數的文章都還是用組積木的方式在介紹 DOM 操作,以避免相容性的問題:

Firefox 48 was released on August 2, 2016 for both desktop and Android.

另外還看到 insert​Adjacent​HTML()insert​Adjacent​Text() 可以用,其中讓我注意到 MDN 上面提到 insert​Adjacent​HTML() 居然是 Firefox 8+?本來以為是 48+ 的誤植,但從 Mozilla 的記錄「Implement insertAdjacentHTML」這邊可以看到,應該是在 Firefox 8 的時候實作的,這樣的話可以當作 insertAdjacentElement() 的替代品 (如果考慮到古早的相容性),只是這邊需要輸入 html string,跟其他操作是是用 element 不太一致...

意外的學到不少歷史故事... @_@

PHP 數字與字串比較的提案

在「Links: February 2019」這邊看到 PHP 社群的提案,想要改善數字與字串比較的結果:「PHP RFC: Saner string to number comparisons」。

他給了一個經典的範例:

$validValues = ["foo", "bar", "baz"];
$value = 0;
var_dump(in_array($value, $validValues));
// bool(true) WTF???

原因是 in_array()== 而非 ===,所以就噴了... 而提案我看了還是覺得不行啊,看看會怎麼改吧 :o

YAML 裡放多行區塊的方式

因為在寫 ansible 的 playbook,有些地方想要偷懶,把檔案放進在 playbook 本身...

網路上搜了一下找到「In YAML, how do I break a string over multiple lines?」這篇,最常用的應該是 ||- 以及 |+ 了,用這三招塞檔案應該是夠用...

裡面的範例拿 JSON 的格式來解釋還蠻有趣的,代表 JSON 真的很好懂...

Trac 1.1 增加的 time 欄位,以及 Due Date 資料的轉移

Trac 的版本玩法跟早期 Linux Kernel 的模式有點像,也就是版號偶數是正式版,奇數是開發版... 雖然現在 Linux Kernel 已經不玩這套了,但 Trac 還是維持這樣的開發方式。

先前一直都是用 Trac 1.0,其中 Due Date 的功能則是用「DateFieldPlugin」這個套件,讓 Trac 支援 date 格式,於是就可以在 [ticket-custom] 裡面指定 Due Date 了:

due_date = text
due_date.date = true
due_date.date_empty = false
due_date.label = Due Date
due_date.value = <now>

在套件的頁面也有提到在 Trac 1.1.1 後就有內建的方式可以用了:

Notice: This plugin is deprecated in Trac 1.2 and later. Custom fields of type ​time were added in Trac 1.1.1.

連結是連到 1.1 的,我要測 1.2 的,所以往現在的版本翻資料,可以看到在 TracTicketsCustomFields 這邊的說明:(這邊就懶的照原來 html 排了,用 pre 直接放縮排)

time: Date and time picker. (Since 1.1.1.)
    label: Descriptive label.
    value: Default date.
    order: Sort order placement.
    format: One of:
        relative for relative dates.
        date for absolute dates.
        datetime for absolute date and time values.

這樣一來設定就會變成:

due_date = time
due_date.format = date
due_date.label = Due Date
due_date.value = now

但底層資料怎麼存?先看 ticket_custom 這個表格的結構,可以看到是 EAV 的架構:

+--------+------------+------+-----+---------+-------+
| Field  | Type       | Null | Key | Default | Extra |
+--------+------------+------+-----+---------+-------+
| ticket | int(11)    | NO   | PRI | NULL    |       |
| name   | mediumtext | NO   | PRI | NULL    |       |
| value  | mediumtext | YES  |     | NULL    |       |
+--------+------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

隨便拉一些可以看出來放法很簡單:

+--------+----------+------------+
| ticket | name     | value      |
+--------+----------+------------+
|      1 | due_date | 2016-10-03 |
+--------+----------+------------+

改成 Trac 1.2 內建的 time 後,塞 2018/02/28 變成:

+--------+----------+--------------------+
| ticket | name     | value              |
+--------+----------+--------------------+
|      1 | due_date | 001519776000000000 |
+--------+----------+--------------------+

拿掉後面的六個 0 後可以看到就是 2018/02/28 了,要注意的是,這邊會受到時區影響,我一開始測試的時候沒調整,寫進去的時間是用伺服器預設的時區計算的。另外也大概能理解前面放兩個 0 的目的,是為了讓 string 比較時的大小就會是數字實際的大小。

$ date --date=@1519776000
Wed Feb 28 00:00:00 UTC 2018

這樣就知道要怎麼做人工轉換了...

PHP 的 Unquoted Strings 將在 PHP 8 被移除

Twitter 上看到 PHP 的 unquoted string 被視為字串的功能將被移除:「PHP RFC: Deprecate and Remove Bareword (Unquoted) Strings」。

常見的情境是 $_GET[bar] 這樣的用法被視為與 $_GET["bar"] 相同... 超奇怪的功能,而現在這個功能已經投票通過,將會在 7.2 被列為 deprecated,到 8 就會拿掉。

這個功能本來是標示 E_NOTICE,但比較特別的是,雖然是列為 deprecated,PHP 7.2 預定會標示為 E_WARNING 而不是 E_DEPRECATED。主要是這次的兩個目標互相衝突 (可以參考原文),取比較有效的那個 (因為 PHP 8 就不會有這個問題了,所以 PHP 7.2 的過渡期以比較容易提醒使用者的那個為主)。

投票是 100% 通過 (41/41)。