GET 與 POST 的差異

看到這篇在講 HTTP (& HTTPS) 裡面 GET 與 POST 的差異,剛好把一些標準的定義拿出來翻一翻,算是複習基本概念:「Get safe」。

第一個基本概念主要是 idempotence (& idempotent),重複被呼叫不會造成狀態的再次改變:

Idempotence ([...]) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.

數學定義是這樣跑:

An element x of a magma (M, •) is said to be idempotent if:

x • x = x.

If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.

這點在 HTTP 標準 (RFC 7231) 裡面的定義也類似:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

第二個基本概念是 Safe method (也是在同樣的 RFC 裡被提到),主要的思想是 read-only,這也是文章作者的標題要講的事情:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

然後標準的 HTTP method 是有定義的:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

不過文章裡面提到的第一個例子並沒有很好,POST 不保證 safe 沒錯,但不代表 safe operation 就不能用 POST。

這邊用 URI resource 的概念 (以及 SEO?) 或是用 Post/Redirect/Get 的概念來說明會比較好:

<form method="get" action="/search">
<input type="search" name="term">

不過文章後續提到的問題的確就是我自己都會犯錯的問題:

“Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.

“Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.

這兩個動作都會造成 server 端的狀態改變,不應該用 GET,而我自己常常忘記第一個... 這邊其實可以用 form 產生 POST 需求,並且用 css 效果包起來,達到看起來跟一般的連結一樣。

寫起來讓自己多一點印象,之後避免再犯一樣的錯誤...

FreeBSD 要從 Subversion 換到 Git

#bsdchat 上面看到 FreeBSD 提供了 Git repository,翻了一下看起來是最近在切換,這邊有翻到慣例的 HEADS UP:「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上:「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去:「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense),但還是先恭喜他們總算要切換了,兩邊的能量差太多了...

Bash Script 的好習慣

這篇給了一份 bash script 用的 tempalte,但更重要的反而是裡面提到的 best practice:「Minimal safe Bash script template」。

首先是不要寫 /bin/bash 這件事情,因為有些系統是沒有 /bin/bash 的,像是 FreeBSD

如果程式是可以用 POSIX sh 語法的話,應該優先考慮 /bin/sh,如果用到非 POSIX 標準的語法的話,用 env 帶出來會少一些問題:

#!/usr/bin/env bash

再來是 fail 時就趕快停止,不要再往下執行,這點算是老生常談了,文章作者也有給一個範例說明:

set -Eeuo pipefail

再來另外一個還蠻有用的事情是攔下常見的 signal 處理「後事」:

trap cleanup SIGINT SIGTERM ERR EXIT

cleanup() {
  trap - SIGINT SIGTERM ERR EXIT
  # script cleanup here
}

其他的可以看一看,但未必要全盤收下...

網頁本身是個合法的 JSON 的展示

Hacker News Daily 上看到「Web Data Render」這個有趣的東西,這個網頁本身是個 JSON,透過一些技巧載入 javascript 後就可以讀取資料 render...

不過網頁本身就不是合法的 HTML 了:「Showing results for https://webdatarender.com/」,只能算是個有趣的作法...

PHP 8.0 快要出了

看到 WordPress 的這篇「WordPress and PHP 8.0」,看起來 PHP 8.0 快要出了:

PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.

官網上已經有一些資料可以看了,不過記得畢竟還沒 release,裡面的資訊還有可能會修正:「Migrating from PHP 7.4.x to PHP 8.0.x」,最重要的應該還是「Backward Incompatible Changes」這邊,可以看到這次畢竟是主版號升級,精彩的不相容性應該會搞爆不少應用程式,像是開頭就提到的,對數字與文字之間的 == 行為改變:

比較好的作法是自己先轉型再用 === 比較,這個概念在各家程式語言都類似,loose comparison 只是方便而已...

挑選開發者用的 Monospace 字型

Hacker News Daily 上看到的網站,直接使用對應的字型,讓使用者可以直接感覺:「Dev Fonts」。

目前上面有 33 種字型,大多都是免費的 (目前上面只有看到 Dank Mono 是收費的字型)。

在頁面上可以換 theme,以及選擇不同程式語言的 syntax highlighter,另外下方範例的程式碼也可以自己修改,這些都是讓使用者模擬實際的感受。

日本郵政的 CSV 資料

看到「Parsing the Infamous Japanese Postal CSV」這篇在抱怨日本郵政提供的 CSV 資料超級糟糕的問題覺得頗「有趣」的,在 Hacker News 上也有人「同病相憐」XDDD:「Parsing the Infamous Japanese Postal CSV (dampfkraft.com)」。

文章作者是「posuto」這個套件的維護人,這個套件讓開發者可以很方便的在 Python 下從郵遞區號推出對應的地點資訊:

import posuto as 〒

🗼 = 〒.get('〒105-0011')

print(🗼)
# "東京都港区芝公園"
print(🗼.prefecture)
# "東京都"
print(🗼.kana)
# "トウキョウトミナトクシバコウエン"
print(🗼.romaji)
# "Tokyo To, Minato Ku, Shibakoen"
print(🗼.note)
# None

作者建立的資料是從「読み仮名データの促音・拗音を小書きで表記するもの(zip形式)」這邊取得並且分析,然後這篇文章就是在描述這些 CSV 檔的資料裡面有超級多奇怪的例外,用機器讀取超哭爸的 XDDD (好像不怎麼意外?)

不過最有趣的應該還是他提到的這個:

Oh, and if you need a Win3.1 or DOS program to copy the data onto an IBM H floppy disk, just check the bottom of JP Post's page - they've got you covered.

看起來是頁面下方的這塊:

這就真的太哭爸了啊 XDDD

新版 PttBBS 用到的 flatbuffers

留個記錄上後面的人知道怎麼編...

我自己有用 PttBBS 架個站自己丟一些東西,本來是想要修改發文時延遲一秒的 sleep(1); 保護 (反正整個站也只有我自己用,patch 在 Remove sleep(1) protection. 這邊),結果升級的過程中間發現 PttBBS 上個月引入了 Google 家的 flatbuffers,就編不過去了...

找了一下找到給 Ubuntu 18.04 (bionic) 用的 PPA,是 1.11 版:「flatbuffers」,裝起來之後發現用了 --filename-suffix 語法,這個功能在 1.12 才被引入:「Added --filename-suffix and --filename-ext to flatc」。

另外就算故意拿掉 --filename-suffix,看起來 fbs 檔內也有用到 1.12 才吃的格式,所以還是照「How to install flatc and flatbuffers on linux ubuntu」這邊講的,乖乖的自己編了一個 flatc 出來用。

編好以後在 ~/.profile 裡面設定 PATH,讓編譯時可以吃到:

export PATH="${HOME}/flatbuffers:${PATH}"

然後再回去 pmake all 應該就會過了,我這邊是遇到記憶體吃爆 OOM 的情況,另外加 swapfile 就解決了...

kernel.org 推動 git push 的簽名

LWN 上看到 kernel.org 解釋並且推動 git push 的電子簽名:「Signed pushes for kernel.org」。

在「Signed git pushes」這篇裡面解釋了除了 git commit 本身的簽名外,另外 git push 的簽名也有重要性。

而在「Introducing the kernel.org git transparency log」這邊則是公開了對應的 git transparency log。

這個方法讓 kernel.org 上的 git repository 會更透明,加上 kernel.org 上的 git repository 會被很多人 mirror,在真的出問題的時候,大家手上也都有資料可以交叉比對...

維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息,維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上:「GitLab consultation」,在 Hacker News 上也有不少討論 (i.e. 戰文):「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看,主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同,也導致了 usability 不怎麼好,這使得社群與基金會的員工的學習成本偏高:

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務,了解後主要列出三個原因:

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了,但其實市場上也沒什麼可以選的,從說明的 FAQ 部份可以看到 GitHub 與 GitLab,另外因為基金會的特性有強烈偏好 open source self-hosting 方案,基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話,我猜不完全是工具的問題,內部應該有不少政治上的問題,只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的,有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。