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 效果包起來,達到看起來跟一般的連結一樣。

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

透過把 .git/safe/../../bin 加到 $PATH 執行程式

在「.git/safe」這邊看到的方式,想要方便執行 $GITROOT/bin 想法是:

  • .git/safe/../../bin 放到 $PATH,如果可以順利解出來的話就是 repository 本身的 $GITROOT/bin
  • 但一般是解不出來的 (因為 .git/ 裡面不會有 safe/ 這個目錄,所以預設是解不出東西的。而對於信任的 repository 則可以 mkdir .git/safe 讓 shell 可以搜尋到。

之所以可以這樣做的是因為:

  • .git 是保留字,從 command line 上你沒辦法塞 .git 目錄進到 repository 內,但不確定直接從 blob layer 塞會怎樣... (也就是得確認 checkout 時檢查的問題)

先寫起來看看好了,不過暫時應該也用不到...

Yahoo! 也放出了判斷是否為色情圖片的方案

感覺好像是從 AlphaGo 大勝李世乭開始,透過各類 neural network 的技術就一直冒出來...

Yahoo! 這次放出來判斷是否為色情圖片的也是同源的技術:「Open Sourcing a Deep Learning Solution for Detecting NSFW Images」。

當年沒辦法做的事情,現在的技術已經成熟到被 open source 出來了...

強迫要求使用者改密碼反而會不安全?

在「Want Safer Passwords? Don't Change Them So Often」這邊在討論改目前 password policy 會有要求一定時間要改密碼造成的問題。原報導出自 美國聯邦貿易委員會 blog 上的「Time to rethink mandatory password changes」。

當你強制要求改密碼時,由於因為是被逼的,他們不會放太多心力:

Lorrie Cranor recently outlined, the weight of recent research agrees that when people are forced to change their passwords on the regular, they don’t put a whole lot of mental muscle behind it.

而在沒有準備的情況下產生出來的密碼將會是比較容易預測的:

Instead, Cranor notes, according to one UNC study, people “tended to create passwords that followed predictable patterns, called ‘transformations,’ such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end).”

另外你應該鼓勵使用者用 password manager 管理密碼,雖然不是完美的,但至少是目前比較合理的方案:

If for whatever reason you still can’t let go of making people change passwords as often as they turn the pages of their wall calendars, Cranor suggests that you at least encourage them to use a password manager, like LastPass or DashLane. They’re not perfect, but they can be a “very reasonable strategy” for coping, mostly because they don’t require people to balance unpredictable passwords with ones they can actually remember.

Google 的 Safe Browsing 將開始阻擋誘導式的頁面

Google 宣布 Safe Browsing 將會把各種誘導式頁面列入清單阻擋:「No More Deceptive Download Buttons」。

Google 給了幾個例子,像是這樣的廣告頁面:

或是這樣的圖片按鈕,試著誤導使用者:

都會被認為是偽裝成官方訊息,意圖讓使用者下載惡意程式而被阻擋。

Berkeley DB 的介紹

在滿滿都是 NoSQL 的世代中,意外在「Berkeley DB: Architecture」這邊看到 Berkeley DB 的介紹...

2006 年 Berkeley DB 的公司 SleepycatOracle 收購。在收購後 Oracle 改變了 open source 授權部份,從之前的 Sleepycat License 改成了 AGPLv3

Berkeley DB 算是早期功能很完整的 database library,由於 page level locking、crash-safe 加上有 transaction,也曾經被 MySQL 拿去當作 engine,不過在 MySQL 5.1 被拔掉:「14.5 The BDB (BerkeleyDB) Storage Engine」。

文章裡講了很多底層設計上的想法 (而非單純只說明「做了什麼」),以四個面向來討論。Buffer、Lock、Log 以及 Transaction,並且圍繞著 ACID 需求討論。

算是懷念的考古文?Google 弄出來的 LevelDBFacebook 接著改善的 RocksDB 的走向也不太一樣了,現在大家對 ACID 需求因為 NoSQL 盛行的關係又重新在檢視...

Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析

Google Online Security 分析了前陣子 GitHub 被 DDoS 攻擊的行為:「A Javascript-based DDoS Attack as seen by Safe Browsing」。

透過 GoogleSafe Browsing,針對 baidu.com 這個網域的 injection 情況分析:

可以看得出來分成多個不同階段攻擊。其中 AWSCloudFront 承受了不小的壓力,不過畢竟是商用水準的 CDN,沒那麼容易垮掉。後來則是攻擊 GitHub 造成影響而上了新聞。

最終還是繼續推廣 TLS,可以避免中間被 injection 攻擊:

Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible.

Percona 講 TokuDB

Percona 的「Getting to know TokuDB for MySQL」這篇文章雖然標題是想要宣傳 TokuDB,但其實把 MySQL 的歷史也講了一遍...

前面講到 InnoDB 的崛起時,就有提到就算你不使用 InnoDB 提供的 transaction,他的 crash-safe 性質也仍然是許多人選用 InnoDB 的重要因素之一:

Even those that don’t really need transactions rejoice in the crash resistance strength of InnoDB.

後面提到 TokuDB 時當然都會提到 Fractal Tree Indexes 這個資料結構對於現代硬體設備的優點。而英文版維基百科在今年三月時總算建立了 Fractal tree index 這個條目,整理的還算完整,之前是去看投影片了解這個資料結構的特性...

Percona 目前對 TokuDB 的等級是放在 beta 版,等 GA 後再來完整的測過一次,另外也想要測能不能在同一個 transaction 內使用 InnoDB table & TokuDB table,這對 zero-downtime migration 還蠻重要的,如果不可行的話工程就比較大了...