Home » Posts tagged "http"

Command Line 的 HTTP 操作工具

忘記在哪邊翻到的:「HTTP Tools Roundup」,裡面有提到一些 Command Line 下操作 HTTP 內容的工具。

其中一個是 HTTPie,這個有時後會拿來用,不過大多數的時候還是習慣用 curl 了 (因為 curl 幾乎都會裝,HTTPie 要另外裝):

另外一個是 http-console,這是第一次看到... 用過後覺得還不錯,應該會記起來用一陣子看看 XD

gslin@home [~] [17:24/W5] http-console --ssl https://emma.pixnet.cc:443/
> http-console 0.6.4
> Welcome, enter .help if you're lost.
> Connecting to emma.pixnet.cc on port 443.

https://emma.pixnet.cc:443/> GET /robots.txt
HTTP/1.1 200 OK
Date: Sat, 11 Nov 2017 09:24:11 GMT
Last-Modified: Tue, 16 Sep 2014 06:45:02 GMT
Etag: "2b-50329173d7780"
Accept-Ranges: bytes
Content-Length: 43
Vary: Accept-Encoding,User-Agent
X-Farmid: ba2629de4a01c1a81a0ad72ff1f11c5d2ae5ed0782561f591105c5a669e4ea49
Access-Control-Allow-Origin: *
Connection: close
Content-Type: text/plain

# emma.pixnet.cc
User-agent: *
Disallow: /

然後再下 GET /glossary/twzipcode 又可以拉出其他東西。

curl 將支援 Brotli 壓縮

Twitter 上看到有人提到 curl 支援 Brotli 了:「HTTP: implement Brotli content encoding」。

Brotli 對文字系列的資料比較有幫助 (像是 html):

Unlike most general purpose compression algorithms, Brotli uses a pre-defined 120 kilobyte dictionary, in addition to the dynamically populated ("sliding window") dictionary. The pre-defined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents. Using a pre-defined dictionary has been shown to increase compression where a file mostly contains commonly-used words.

現在還在 master 裡面,之後的 release 版本應該就會支援了...

HTTP/2 時代的 API 設計

在「Let’s Stop Building APIs Around a Network Hack」這邊提到了以前為了解決 HTTP/1.1 的問題而發展出來的 workaround,在 2015 年發展出來的 HTTP/2 從底層直接解了不少問題,加上很快被許多瀏覽器支援 (就算不支援 HTTP/2 也只是降到 HTTP/1.1 跑,比較慢而已):

Guess what else was released in May 2015? RFC 7540, otherwise known as HTTP/2. In retrospect this seems highly poetic, as HTTP/2 kinda makes the compound document aspect of JSON-API a little bit pointless, and compound documents to me go hand in hand with what JSON-API is as a standard.

2012 年在 MOPCON 第一屆講的「API Design Optimized for Mobile Platform」剛好就是這個主題:

有種懷念感... XD

Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

Google 打算更廣泛的預設使用 HSTS

Google 宣佈了更廣泛開啟 HSTS 的計畫:「Broadening HSTS to secure more of the Web」。

然後先提到 .foo.dev 的「Google Chrome 將 .dev 設為 HSTS Preload 名單」這件事情:

In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.


We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Apache 的 Optionsbleed

Apache 也出了類似 Heartbleed 的包:「Apache bug leaks contents of server memory for all to see—Patch now」,原文出自「Optionsbleed - HTTP OPTIONS method can leak Apache's server memory」。

這掛上 CVE-2017-9798 了,影響版本包括了:

This affects the Apache HTTP Server through 2.2.34 and 2.4.x through 2.4.27.

發生在對 OPTIONS 處理出問題:

Optionsbleed is a use after free error in Apache HTTP that causes a corrupted Allow header to be constructed in response to HTTP OPTIONS requests. This can leak pieces of arbitrary memory from the server process that may contain secrets. The memory pieces change after multiple requests, so for a vulnerable host an arbitrary number of memory chunks can be leaked.

就... 更新吧 @_@

Mozilla 的提案「HTTP Immutable Responses」

狀態已經是 Category: Standards Track 了,RFC 8246 的「HTTP Immutable Responses」:

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

Cache-Control 介紹了 immutable,像是這樣:

Cache-Control: max-age=31536000, immutable

依照 MDN 上的資料 (Cache-Control - HTTP | MDN),目前只有 EdgeFirefox 支援,不過既然成為標準了,後續其他瀏覽器應該都會支援 (吧):

nginx 的 mirror 功能

nginx 1.13.4 出的新功能,ngx_http_mirror_module

The ngx_http_mirror_module module (1.13.4) implements mirroring of an original request by creating background mirror subrequests. Responses to mirror subrequests are ignored.


location / {
    mirror /mirror;
    proxy_pass http://backend;

location /mirror {
    proxy_pass http://test_backend$request_uri;

如果拿 nginx 當 load balancer 的人,可以用這個功能做些事情...