Tag Archives: response

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

Amazon API Gateway 支援壓縮了...

Amazon API Gateway 支援壓縮了:「Amazon API Gateway Supports Content Encoding for API Responses」。

You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.

打開後傳回的資料就會自動壓縮了,然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway),目前支援的壓縮格式應該是最常見的 gzipdeflate

這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...

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 支援,不過既然成為標準了,後續其他瀏覽器應該都會支援 (吧):

Lambda@Edge 的 GA

AWSLambda@Edge 宣佈 GA 了:「Lambda@Edge – Intelligent Processing of HTTP Requests at the Edge」。

最直接的應用就是在 CloudFront 的 edge 上執行一小段 code,修改 HTTP request 或是 HTTP response 了,不過可以看到一些限制:

不過要用來解哪些問題要再想一下...

HTTP Header 裡的 Location 使用相對路徑...

HTTP Response Header 的 Location (俗稱「轉址」) 被用在不少地方,剛好今天被 ccn 戳到相關的問題...

在維基百科的「HTTP location」條目裡面有說明 HTTP/1.1 的規範裡要求必須是 absolute URI:

Location       = "Location" ":" absoluteURI

但實務上,目前市場上常見的瀏覽器都支援相對路徑。而且在 HTTP/1.1 修正版 (目前還在 draft) 裡被修正成:

Location = URI-reference

並且說明 relative 時的判定方式:

The field value consists of a single URI-reference. When it has theform of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).

所以就大膽用吧...

429 Too Many Requests

剛剛在「Apache HTTP ServerをRFC6585の"429 Too Many Requests"に(とりあえず)対応させるパッチ」看到的... 429 Too Many Requests 是在四月才被提出來的 (RFC 6585),雖然還不是 Standard (目前是 Proposed Standard),但看起來不錯啊...

一定要放一張經典畫面...