1. 序論
この仕様は、 `QUERY$m `~method$を定義する — ~HTTPにおいて，次のような`要請$を為すための手段として： ◎ This specification defines the HTTP QUERY request method as a means of making＼
- `安全$かつ`冪等$である ◎ a safe, idempotent request (Section 9.2 of [HTTP])＼
- ［ 当の要請が`~target資源$により どう処理されるようになるか ］を述べている`表現$を同封する ◎ that encloses a representation describing how the request is to be processed by the target resource.
共通的な~query~patternは： ◎ A common query pattern is:
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1 Host: example.org
しかしながら，この~patternは、 伝達される~dataが`要請~target$【！要請の~URI】内に符号化するには長大過ぎるときは，問題になり得る： ◎ However, when the data conveyed is too voluminous to be encoded in the request's URI, this pattern becomes problematic:
- ~URIの~size上限は、 事前に既知でないことが多い — 要請は、 互いに協調しない多くの~systemを通過し得るので。 （が、 `HTTP$r `~URI参照＠~HTTPinfra#uri.references§ は［ `送信者$, `受信者$ ］に 8000 ~octet以上を~supportするよう推奨していることに注意）。 ◎ size limits often are not known ahead of time because a request can pass through many uncoordinated systems (but note that Section 4.1 of [HTTP] recommends senders and recipients to support at least 8000 octets),
- ~dataの種類によっては、 `~target~URI$内に表出することは，効率的でない — そのような~dataを妥当な~URIの中へ符号化することには~overheadがあるので。 ◎ expressing certain kinds of data in the target URI is inefficient because of the overhead of encoding that data into a valid URI,
- `要請~target$【！要請~URI】は、 要請の`内容$よりも~logされる見込みが高いことに加え， ~bookmarkにも転用され得る。 ◎ request URIs are more likely to be logged than request content and may also turn up in bookmarks,
- ~queryを`要請~target$【！要請~URI】の中へ直に符号化することは、 実質的に，~query入力を成す あらゆるアリな組合nそれぞれを別個な`資源$として配役することでもある。 ◎ encoding queries directly into the request URI effectively casts every possible combination of query inputs as distinct resources.
`GET$m ~methodを利用することの代替として、 多くの実装は， `POST$m ~methodを用立てて~queryを遂行する — 下の例で~~説明されるとおり。 この事例では、 ~query演算に対する入力は，要請の`内容$として渡される — `要請~target$【！request URI】の `query$p 成分を利用するのではなく。 ◎ As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example below. In this case, the input to the query operation is passed as the request content as opposed to using the request URI's query component.
ある~queryを要請している `POST$m の典型的な利用： ◎ A typical use of HTTP POST for requesting a query is:
POST /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-published
しかしながら，この~~代替策においては、 要請の送信-先である［ `資源$や`~server$ ］に特有な知識を伴わない下では， `安全$かつ`冪等$な~queryを遂行するかどうかが事前に明らかにならない。 ◎ In this variation, however, it is not readily apparent -- without specific knowledge of the resource and server to which the request is being sent -- that a safe, idempotent query is being performed.
`QUERY^m ~methodは、 `GET$m の利用と `POST$m の利用の隙間を~~埋める解決策を供する — 上の例が，次として表出されるよう： ◎ The QUERY method provides a solution that spans the gap between the use of GET and POST, with the example above being expressed as:
QUERY /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-published
~query演算への入力は、 `POST$m と同じく，要請の`内容$として渡される — `要請~target$【！要請~URI】の一部としてではなく。 しかしながら， `POST$m と違って、 この~methodは明示的に`安全$かつ`冪等$であり， ~cachingや自動的な再試行の様な機能を運用することを許容する。 ◎ As with POST, the input to the query operation is passed as the content of the request rather than as part of the request URI. Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
この仕様は、［ 重要な資源は~URIにより識別される~OUGHT ］という設計~原則を認識する下で， `~server$が［ ~query自体, 特定の~query結果 ］に~URIを — `GET$m 要請における今後の利用~用に — どうアテガえるかを述べる。 ◎ Recognizing the design principle that any important resource ought to be identified by a URI, this specification describes how a server can assign URIs to both the query itself or to a specific query result, for later use in a GET request.
次の表tに，これら関連な各~methodの特質を要約する：
| `GET$m | `QUERY$m | `POST$m | |
|---|---|---|---|
| `安全$か | はい | はい | いいえになり得る |
| `冪等$か | はい | はい | いいえになり得る |
| ~query自体への~URI | はい（定義により） | 任意選択（ `Location$h 応答~field） | いいえ |
| ~query結果への~URI | 任意選択（ `Content-Location$h 応答~field） | ||
| `~cache可能$か | はい | はい | はい — ただし，未来の［ `GET$m ／ `HEAD$m ］要請~用に限る。 |
| `内容$（本体） | “定義された意味論は無い” | 期待される（意味論は`~target資源$に従う） | |
1.1. 各種用語
この文書は、 `HTTP$r `各種用語と中核~概念＠~HTTPinfra#terminology§ にて定義される各種用語を利用する。 ◎ This document uses terminology defined in Section 3 of [HTTP].
加えて，次に挙げる用語も利用する：
- `~URI~query~parameter@ は、 ~URIの `query$p 成分~内の~parameterを指す。
- `~query内容@ は、 `QUERY$m 要請の`内容$を指す。
1.2. 表記上の規約
この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
2. `QUERY^m ~method
`QUERY^m ~methodは、 ~server側の~queryを起動するために利用される。 `GET$m ~methodは、 `~target~URI$により識別される`資源$の`表現$を要請するが （ `HTTP$r `~target資源の決定-法＠~HTTPsem#target.resource§ にて定義されるとおり）， それとは違って `QUERY^m ~methodは、 `~target資源$の視野の中で~query演算を遂行するよう，~target資源に依頼するために利用される。 ◎ The QUERY method is used to initiate a server-side query. Unlike the GET method, which requests a representation of the resource identified by the target URI (as defined by Section 7.1 of [HTTP]), the QUERY method is used to ask the target resource to perform a query operation within the scope of that target resource.
~queryは、［ `QUERY^m 要請の`内容$, それに結付けられた`~MIME型$ ］により定義される。 ~query演算の視野は、 `生成元~server$が`~target資源$に基づいて決定する。 ◎ The content of the request and its media type define the query. The origin server determines the scope of the operation based on the target resource.
~serverは、 当の要請の `Content-Type$h ~fieldが［ 欠落である場合／当の要請の内容と整合でない場合~FN ］には， 当の要請を失敗させなければナラナイ。 ◎ Servers MUST fail the request if the Content-Type request field ([HTTP], Section 8.3) is missing or is inconsistent with the request content.
【~FN すなわち、 当の内容は，当の`~field値$にて指定された`~MIME型$に定義される形式として妥当でない場合。 】
`~target~URI$の `query$p 成分【！query part】は、 他のすべての`~method$と同じく， ~queryされている`資源$の識別-法の一部を成す。 `query$p 成分が~queryの結果に［ 直に影響するか否か, どう影響するか ］は、 当の資源に特有であり，この仕様の視野から外れる。 ◎ As for all HTTP methods, the target URI's query part takes part in identifying the resource being queried. Whether and how it directly affects the result of the query is specific to the resource and is out of scope for this specification.
`QUERY^m 要請は、 `~target資源$に関して`安全$である — すなわち、 ~clientは，~target資源の状態に対する変更を何ら要請しないし, 期待しない。 これは、 ~serverが追加的な — それを通して追加的な情報を検索取得できるような — `資源$を作成することを防止するものではない。 （ `2.3＠#content-location§, `2.4＠#location§ を見よ）。 ◎ QUERY requests are safe with regard to the target resource ([HTTP], Section 9.2.1); that is, the client does not request or expect any change to the state of the target resource. This does not prevent the server from creating additional HTTP resources through which additional information can be retrieved (see Sections 2.3 and 2.4).
`QUERY^m 要請は、 `冪等$でもある — それは、 必要なときは（一例として，接続に失敗した後に）［ 試行し直せる／繰返せる ］。 ◎ Furthermore, QUERY requests are idempotent ([HTTP], Section 9.2.2); they can be retried or repeated when needed, for instance, after a connection failure.
状態s~code `2xx$st を伴う応答は、 その定義により，当の応答が応対した要請は成功裡に［ 受信され, 解され, 受容された ］ことを通達する。 ◎ As per Section 15.3 of [HTTP], a 2xx (Successful) response code signals that the request was successfully received, understood, and accepted.
特に， `200$st 応答は、［ 当の~queryは成功裡に処理され，その結果は当の応答の`内容$として同封された ］ことを指示する。 ◎ In particular, a 200 (OK) response indicates that the query was successfully processed and the results of that processing are enclosed as the response content.
2.1. ~MIME型と内容~折衝
`QUERY^m 要請の意味論は、 当の要請の`内容$, 当の要請に結付けられた~metadata【特に，`表現~metadata$】 — `~MIME型$など — どちらにも依存する。 要請に［ 内容と~metadataが整合でない問題 ］がある場合、 一般に， `4xx$st 応答で却下されなければナラナイ。 ◎ The semantics of a QUERY request depend both on the request content and the associated metadata, such as the media type ([HTTP], Section 8.3.1). In general, any problem with requests where content and metadata are inconsistent MUST be rejected with a 4xx (Client Error) response ([HTTP], Section 15.5).
以下の~listは、 失敗になる様々な事例を述べることに加え， 各~事例に特有な`状態s~code$を推奨する — 以下における［ %~MIME型 は当の要請にて指定された`~MIME型$（もしあれば）／ %内容 は当の要請の`内容$／ %資源 は【当の要請の`要請~target$により識別される】`~target資源$ ］を指すとする： ◎ The list below describes various cases of failures and recommends specific status codes:
- 当の要請 は %~MIME型 を欠如している場合 ⇒ 要請は、 定義により不正であり， 状態s~code `4xx$st0 — `400$st など — で失敗する必要がある。 ◎ If a request lacks media type information, it is incorrect by definition and needs to fail with a 4xx status code such as 400 (Client Error).
-
%~MIME型 は指定されたが， %資源 は それを~supportしない場合 ⇒ `415$st が適切になる。 ◎ If a media type is specified but is not supported by the resource, a 415 (Unsupported Media Type) is appropriate.＼
これは、 特定的に，［ %~MIME型 は、 原則においては既知であるが，［ %資源 に対する `QUERY^m ］に特有な意味論を欠如する事例 ］を含む。 どちらの事例でも、 %資源 が~supportする`~MIME型$を~clientに伝えるためとして， 対する応答~内に `Accept-Query$h ~fieldを利用できる。 ◎ This specifically includes the case where the media type is known in principle, but it lacks semantics specific to a QUERY to the target resource. In both cases, the Accept-Query response field (Section 3) can be used to inform the client of the media types that are supported.
-
%~MIME型 は指定されたが， 実際には %内容 と整合でない場合 ⇒ `400$st を返せる。 ◎ If a media type is specified but is inconsistent with the actual request content, a 400 (Bad Request) can be returned.＼
すなわち、 ~serverには， “内容~sniff法” — %内容 から`~MIME型$を推定した結果により［ 欠落な／ “誤りがある” ］値を上書きすること — は許容されない。 ◎ That is, a server is not allowed to infer a media type from the request content and then override a missing or "erroneous" value (i.e., "content sniffing").
-
%~MIME型 は指定され, 解され， %内容 は~~実際に %~MIME型 と整合するが、 %内容 が成す実際の~queryに因り，当の~queryを処理できない場合 ⇒ `422$st を利用できる。 ◎ If the media type is specified and understood, and the content is indeed consistent with the type, but the query cannot be processed due to the actual contents of the query, the status 422 (Unprocessable Content) can be used.＼
例えば、 構文上は正しい~SQL~queryであるが，存在しない~tableを識別するもの。 ◎ An example would be a syntactically correct SQL query that identifies a non-existent table.
- ~clientは `Accept$h ~fieldを利用して， 特定の応答`~MIME型$を要請したが、 %資源 はそれを~supportしない場合 ⇒ `406$st が適切になる。 ◎ If the client requests a specific response media type using the Accept field ([HTTP], Section 12.5.1) that is not supported by the resource, a status code of 406 (Not Acceptable) is appropriate.
2.2. 等価な資源
所与の `QUERY^m 要請 %要請 用の `等価な資源@ とは、 `GET$m 要請に対し応答する`資源$のうち［ %要請, %要請 の`~target資源$ ］を %要請 の［ `内容$, ~metadata ］どちらも織り込んで表現するものである。 特に，この~metadataには、 `表現~metadata$ — 当の内容の`~MIME型$など — も含まれる。 ◎ The equivalent resource for any given QUERY request is a resource that responds to GET requests, represents that QUERY request and its target, and takes both message content and metadata into account (Section 6 of [HTTP]). In particular, this includes representation metadata (Section 8 of [HTTP]) such as the content's media type.
言い換えれば，`等価な資源$は、 `QUERY^m を実装している`資源$から， 当の要請の`内容$を組入れることにより導出される。 ◎ In other words, the equivalent resource is derived from the resource implementing QUERY by incorporating the request content.
用語`等価な資源$は、 ~HTTPを成す他の側面 — `選定された表現$など — 用の挙動を定義するための手段として利用される。 `~server$は、 そのような資源に`~URI$【！`URI$r `1.1＠~RFCx/rfc3986#section-1.1§】をアテガえるが， そうする必要もない — そうする場合、 そのような資源は， `GET$m 要請~用に~access可能になることになる。 ◎ The term equivalent resource is used as a means to define behavior for other HTTP aspects, such as selected representations. Servers can but do not have to assign URIs to these resources (see Section 1.1 of [URI]). If they do so, these resources will become accessible for GET requests.
2.3. `Content-Location^h 応答~field
`QUERY^m 要請に対する成功裡な応答（ `2xx$st0 ）は、［ 当の演算の結果に対応している`資源$ ］用の識別子を包含する `Content-Location$h ~header `HTTP$r も内包できる。 これは、［ ~clientは、 指示された~URIへ `GET$m 要請を送信することで， たった今 遂行した~query演算の結果を検索取得できる ］ものと［ ~serverが主張している ］ことを表現する。 指示された資源は一時的かもしれない。 ◎ A successful response (2xx, Section 15.3 of [HTTP]) can include a Content-Location header field containing an identifier for a resource corresponding to the results of the operation; see Section 8.7 of [HTTP] for details. This represents a claim from the server that a client can send a GET request for the indicated URI to retrieve the results of the query operation just performed. The indicated resource might be temporary.
その例は、 `A.4.1＠#example.content-location§を見よ。 ◎ See Appendix A.4.1 for an example.
2.4. `Location^h 応答~field
`~server$は、 `QUERY^m 要請~用の`等価な資源$に ある~URIをアテガえる。 そうする場合、 `~server$は，対する `2xx$st0 応答の `Location$h ~header `HTTP$r 内に当の資源の~URIを内包できる。 これは、［ `~client$は、 指示された~URIへ `GET$m 要請を送信することで， たった今 遂行した~query演算を`~query内容$を送信し直すことなく繰返せる ］ものと主張していることを表現する。 この`資源$の~URIは、 一時的かもしれない — 未来の要請が失敗した場合、 ~clientは，［ 元の `QUERY^m 要請の`要請~target$と前回に提出した`内容$ ］を利用して試行し直せる。 ◎ A server can assign a URI to the equivalent resource (Section 2.2) of a QUERY request. If the server does so, the URI of that resource can be included in the Location header field of the 2xx response (see Section 10.2.2 of [HTTP]). This represents a claim that a client can send a GET request to the indicated URI to repeat the query operation just performed without resending the query content. This resource's URI might be temporary; if a future request fails, the client can retry using the original QUERY request target and the previously submitted content.
その例は、 `A.4.2＠#example.location§ を見よ。 ◎ See Appendix A.4.2 for an example.
2.5. ~redirection
`~server$は、 一部の事例では， `QUERY^m 要請に対し間接的に応答することを選んでもよい — `~UA$を異なる~URIへ~redirectすることにより （ `HTTP$r `3xx§st を見よ）。 ◎ In some cases, the server may choose to respond indirectly to the QUERY request by redirecting the user agent to a different URI (see Section 15.4 of [HTTP]).
`QUERY^m 要請に対する状態s~code［ `301$st ／ `308$st ］を伴う応答は、 `~target資源$は［ 当の応答の `Location$h ~fieldにより参照される異なる~URI ］へ恒久的に移動されたことを指示する。 同様に，［ `302$st ／ `307$st ］を伴う応答は、 `~target資源$は一時的に移動されたことを指示する。 これらいずれの事例も、 ~serverは次を示唆している ⇒ `~UA$は、 元の `QUERY^m 要請を［ `Location$h により参照される新たな`~target~URI$へ類似な `QUERY^m 要請を送信する ］ことにより成遂げれる。 ◎ A response with either status codes 301 (Moved Permanently, [HTTP], Section 15.4.2) or 308 (Permanent Redirect, [HTTP], Section 15.4.9) indicates that the target resource has permanently moved to a different URI referenced by the Location response field ([HTTP], Section 10.2.2). Likewise, a response with either status codes 302 (Found, [HTTP], Section 15.4.3) or 307 (Temporary Redirect, [HTTP], Section 15.4.8) indicates that the target resource has temporarily moved. In all four cases, the server is suggesting that the user agent can accomplish its original QUERY request by sending a similar QUERY request to the new target URI referenced by the Location.
`POST$m 要請を［ 対する［ `301$st0 ／ `302$st0 ］応答の後には `GET$m 要請として~redirectする ］ための例外は、 `QUERY^m 要請には適用されないことに注意。 ◎ Note that the exceptions for redirecting a POST as a GET request after a 301 or 302 response do not apply to QUERY requests.
`QUERY^m 要請に対する状態s~code `303$st を伴う応答は、 元の~queryは［ `Location$h により参照される~URIに対する通常の検索取得~要請 ］を介して成遂げれることを指示する。 このことは、 ~HTTP用には， `GET$m 要請を新たな`~target~URI$へ送信することを意味する — `~redirectされる応答＠#example.indirect§ 内の例にて~~説明されるとおり。 ◎ A response to QUERY with the status code 303 (See Other, Section 15.4.4 of [HTTP]) indicates that the original query can be accomplished via a normal retrieval request on the URI referenced by the Location response field ([HTTP], Section 10.2.2). For HTTP, this means sending a GET request to the new target URI, as illustrated by the example in Appendix A.4.3.
2.6. 条件付き要請
`QUERY^m 要請に対し`選定される表現$は、 当の要請~用の`等価な資源$への `GET$m 要請に対し`選定される表現$と同じになる。 ◎ The selected representation (Section 3.2 of [HTTP]) of a QUERY request is the same as for a GET request to the equivalent resource (Section 2.2) of that QUERY request.
条件付き `QUERY^m 要請に対する応答~内に`選定された表現$ （すなわち、 `内容~折衝$（もしあれば）の後における~query結果）が返されるのは、 `HTTP$r `条件付き要請＠~HTTPsem#conditional.requests§【内の特に，`事前条件の評価＠~HTTPsem#evaluation§】にて定義されるとおり， `条件付き要請~header$（たち）により述べられる状況下に限られる。 ◎ A conditional QUERY requests that the selected representation (i.e., the query results after any content negotiation) be returned in the response only under the circumstances described by the conditional header field(s), as defined in Section 13 of [HTTP].
その例は、 `A.5＠#example.conditional§を見よ。 ◎ See Appendix A.5 for examples.
2.7. ~cache法
`QUERY^m ~methodに対する応答は、 `~cache可能$である — ~cacheは、 それを利用して，後続な `QUERY^m 要請を満足してもヨイ （ `HTTP-CACHING$r `~cacheからの応答の構築-法＠~HTTPcache#constructing.responses.from.caches§ に従う下で）。 ◎ The response to a QUERY method is cacheable; a cache MAY use it to satisfy subsequent QUERY requests as per Section 4 of [HTTP-CACHING].
`QUERY^m 要請~用の`~cache~key$ `HTTP-CACHING$r には、［ 当の要請の`内容$, 関係する~metadata【特に，`表現~metadata$】 ］ `HTTP$r を組入れなければナラナイ。 ◎ The cache key for a QUERY request (Section 2 of [HTTP-CACHING]) MUST incorporate the request content (Section 6 of [HTTP-CACHING]) and related metadata (Section 8 of [HTTP]).
~cacheは、 ~cache効率を改善するためとして， まず［ 要請の`内容$, 関係する~metadata ］における意味論的に有意でない相違点を除去してもヨイ — 一例として，次に行うことにより： ◎ To improve cache efficiency, caches MAY remove semantically insignificant differences from request content and related metadata first. For instance, by:
- `内容~符号法$（たち）を除去する。 ◎ removing content encoding(s) (Section 8.4 of [HTTP]).
-
当の要請が `Content-Type$h ~fieldを伴う場合、 その値に与えられた`~MIME型$ %~MIME型 を利用して： ◎ ↓
- %~MIME型 の下位型を成す接尾辞 （例： "`+json^c" — `RFC6838$r `4.2.8＠~RFCx/rfc6838#section-4.2.8§ を見よ） により指示される形式~規約に関する知識に基づいて正規化する。 ◎ normalizing based upon knowledge of format conventions, as indicated by any media subtype suffix in the request's Content-Type field (e.g., "+json"; see Section 4.2.8 of [RFC6838]).
- %~MIME型 により指示される［ 当の`内容$自体の意味論に関する知識 ］に基づいて正規化する。 ◎ normalizing based upon knowledge of the semantics of the content itself, as indicated by the request's Content-Type field.
そのような形式変換は、 もっぱら，`~cache~key$を生成する目的で遂行されることに注意 — それは、 当の要請~自体を変更するものではない。 ◎ Note that any such transformation is performed solely for the purpose of generating a cache key; it does not change the request itself.
~clientは、 `no-transform＠~HTTPcache#cache-request-directive.no-transform$dir ~cache指令を利用して， そのような形式変換が起こらないよう望むことを指示できる （が、 この指令は，助言的でしかないことに注意）。 ◎ Clients can indicate, using the "no-transform" cache directive (Section 5.2.1.6 of [HTTP-CACHING]) that they wish that no such transformation happens (but note that this directive is just advisory).
`QUERY^m 要請に対する応答の~cache法は、 内来的に， `GET$m 要請に対する応答の~cache法より複階的であることに注意 — `~cache~key$を決定するためには、 当の要請の`内容$を完全に読取ることが必要になるので。 `QUERY^m に対する応答が`等価な資源$用の~URIを指示するために `Location$h 応答~fieldを給する場合（ `2.4＠#location§ ）、 `~client$は、 後続な各~要請を `GET$m へ切替えることにより，処理を単純~化できる。 ◎ Note that caching QUERY method responses is inherently more complex than caching responses to GET, as complete reading of the request's content is needed in order to determine the cache key. If a QUERY response supplies a Location response field (Section 2.4) to indicate a URI for an equivalent resource (Section 2.2), clients can switch to GET for subsequent requests, thereby simplifying processing.
2.8. 範囲~要請
`QUERY^m ~method用の`範囲~要請$の意味論は、 — `HTTP$r `範囲~要請＠~HTTPsem#range.requests§にて定義されるとおり， `GET$m 用のそれと一致する。 しかしながら、 `~byte範囲$を伴う要請（これを書いた時点で定義-済みな唯一の`範囲~単位$）が `QUERY^m 要請の結果~用に提供する価値は，無いに等しい。 ◎ The semantics of Range Requests for QUERY are identical to those for GET, as defined in Section 14 of [HTTP]. Byte Range Requests (the only range unit defined at the time of writing), however, offer little value for the results of a QUERY request.
各~query形式は、 `QUERY^m 要請の結果を［ 制限する／~pageする【何らかの単位で分割する】 ］仕方として自前のものを定義することが多い — ~SQLにおける "`FETCH FIRST … ROWS ONLY^c" など。 そのような組込みの特能が，`範囲~要請$の代わりに利用されることになるものと予期される。 ◎ Query formats often define their own way of limiting or paging through result sets, such as with "FETCH FIRST ... ROWS ONLY" in SQL. It is expected that these built-in features will be used instead of HTTP Range Requests.
3. `Accept-Query^h ~header
`資源$は、 `QUERY^m ~method用の~supportと伴に［ 当の資源に利用してもよい特定の~query形式の`~MIME型$（たち） ］を直に通達するためとして， `Accept-Query^h 応答~headerを利用できる。 ◎ The "Accept-Query" response header field can be used by a resource to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used.
`Accept-Query^h は、 `有構造~field$の構文 `STRUCTURED-FIELDS$r を利用して， ~MIME型~範囲【！media range】（ `media-range$p `HTTP$r ）たちを包含する。 それは、 `有構造~header$であり，その`~field値$として`~sf~list$をとる — この~listを成す各`~sf~item$の：
- 値は、［ `~sf~token$／`~sf文字列$ ］である — それは、［ `media-range$p を成す `parameters$p 以外の部分 ］を表現する。
- `~sf~parameter群$は、 `media-range$p を成す `parameters$p を表現する。 それを成す各`~sf~parameter$の値は、［ `~sf~token$／`~sf文字列$ ］である。
［ `~sf~token$, `~sf文字列$ ］どちらを選んでも，意味論的には有意でない。 すなわち、 `受信者$は`~sf~token$を`~sf文字列$へ変換してもヨイが， それらの処理-法を受信した型に基づいて違えてはナラナイ。 ◎ The choice of Token versus String is semantically insignificant. That is, recipients MAY convert Tokens to Strings, but MUST NOT process them differently based on the received type.
~MIME型には，`~sf~token$へは正確に対応付けられないものもある — 一例として、 それらは先頭に数字を許容する。 その様な事例では、 `~sf文字列$を利用する必要がある。 ◎ Media types do not exactly map to Tokens; for instance, they allow a leading digit. In cases like these, the String format needs to be used.
~MIME型~範囲における~wildcard（ `*^c ）の利用として~supportされるのは、 次のいずれかに限られる： ◎ The only supported uses of wildcards are＼
- "`*/*^c" ⇒ どの~MIME型【！型】にも合致する。 ◎ "*/*", which matches any type,＼
- "`type/*^c" ⇒ 指示された~MIME型【！型】 %type を成すどの下位型にも合致する。 ◎ or "xxxx/*", which matches any subtype of the indicated type.
この~headerの`~field値$に~listされる~MIME型たちの順序は、 有意でない。 ◎ The order of types listed in the field value is not significant.
`Accept-Query^h ~fieldの値は、 ~server上の同じ~pathを共有する あらゆる~URIに適用される — 言い換えれば、 ~URIの `query$p 成分は無視される。 同じ`資源$への要請たちが異なる `Accept-Query^h 値を返す場合、 最も近過去に受信した新鮮な値が利用される （ `HTTP-CACHING$r `鮮度＠~HTTPcache#expiration.model§ に従って）。 ◎ The value of the Accept-Query field applies to every URI on the server that shares the same path; in other words, the query component is ignored. If requests to the same resource return different Accept-Query values, the most recently received fresh value (per Section 4.2 of [HTTP-CACHING]) is used.
例えば： ◎ For example:
Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"
この~field用の構文は，他の~field — `Accept$h `HTTP$r など — の構文と~~見かけは類似するが、 `有構造~field$であるので， `STRUCTURED-FIELDS$r `4＠~STRUCTURED-FIELDS#text§ にて指定されるとおりに処理しなければナラナイ。 ◎ Although the syntax for this field appears to be similar to other fields, such as "Accept" (Section 12.5.1 of [HTTP]), it is a Structured Field and thus MUST be processed as specified in Section 4 of [STRUCTURED-FIELDS].
4. ~securityの考慮点
`QUERY^m ~methodは、 `HTTP$r にて述べられるとおり，［ すべての`~method$と同じ一般な~security考慮点 ］の~subjectになる。 ◎ The QUERY method is subject to the same general security considerations as all HTTP methods as described in [HTTP].
`QUERY^m ~methodは、［ `~URI$内（例： `query$p 成分）に要請~情報を渡すこと ］の代替として利用できる。 一部の事例では、 これが選好される — ~URIは、 要請の`内容$よりも［ ~logされたり，`媒介者$により処理される ］見込みが高いので。 特に【！other】，当の~queryが敏感な情報を包含する事例では、 ~URIが~logされ得ることが， `GET$m よりも `QUERY^m を利用する動機にもなろう。 ◎ It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.
`~server$は、 ある `QUERY^m 要請に対し， その結果を表現する一時的な`資源$を作成して, それに ある`~URI$をアテガう場合 （例： `Location$h や `Content-Location$h ~fieldにおける利用~用に）、 当の要請が［ ~logさせ得ない敏感な情報 ］を包含する場合には，当の~URIを［ 当の要請を成す敏感な部位を内包しない ］ように選ぶベキである。 ◎ If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field), assigns a URI to that resource, and the request contains sensitive information that cannot be logged, then that URI SHOULD be chosen such that it does not include any sensitive portions of the original request content.
`~cache$が `QUERY^m 要請の`内容$を不正に — あるいは、［ 当の要請の`~target資源$【！the resource】が当の内容を処理する方法 ］とは有意に異なる仕方で — 正規化する場合【`~cache法＠#caching§ を見よ】、 その結果が偽陽性である場合に，不正な応答を返し得る。 ◎ Caches that normalize QUERY content incorrectly or in ways that are significantly different from how the resource processes the content can return an incorrect response if normalization results in a false positive.
`~CORS＠~FETCH#http-cors-protocol$（ `Cross-Origin Resource Sharing^en ）を実装している`~UA$からの `QUERY^m 要請には、 `~CORS予行~要請＠~FETCH#cors-preflight-request$が要求されることになる — `QUERY^m は、 `~CORS安全とされる~method＠~FETCH#cors-safelisted-method$ではないので。 `FETCH$r ◎ A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).
5. ~IANA考慮点
5.1. `QUERY^m ~methodの登録
~IANAは、 `~HTTP~method~registry＠~IANA-a/http-methods$cite に `QUERY^m ~methodを追加した （ `HTTP$r `~method~registry＠~HTTPinfra#method.registry§ を見よ）。 ◎ IANA has added the QUERY method to the "Hypertext Transfer Protocol (HTTP) Method Registry" at <http://www.iana.org/assignments/http-methods> (see Section 16.3.1 of [HTTP]).
| ~method名 | `安全$か | `冪等$か | 仕様 |
|---|---|---|---|
| `QUERY^m | はい | はい | ~RFC 10008 `§ 2＠#query$ |
5.2. `Accept-Query^h ~fieldの登録
~IANAは、 `~HTTP~field名~registry＠~IANA-a/http-fields$cite に `Accept-Query^h ~fieldを追加した （ `HTTP$r `~field名~registry＠~HTTPinfra#fields.registry§ を見よ）。 ◎ IANA has added the Accept-Query field to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> (see Section 16.1.1 of [HTTP]).
| ~field名 | 位置付け | 有構造~型 | 参照 | ~comment |
|---|---|---|---|---|
| `Accept-Query^h | 恒久的 | `~sf~list$ | ~RFC 10008 `3＠#field.accept-query§ |
付録 A. 例
以下に挙げる各~例は、 ~~説明~目的に限られる。 このような短い~queryを実際に送信する必要がある場合、 `GET$m を利用する方が良くなる見込みが高い。 ◎ The examples below are for illustrative purposes only; if one needs to send queries that are actually this short, it is likely better to use GET.
ほとんどの例では、 【 `QUERY^m 要請の`内容$の】`~MIME型$には `application/x-www-form-urlencoded＠~URL1#application/x-www-form-urlencoded$c `URL$r が利用される （~browser~UAが `POST$m 要請に利用するものと同じ）。 ~~簡潔にするため、 `Content-Length$h ~fieldは省略される。 ◎ The media type used in most examples is "application/x-www-form-urlencoded" (as used in POST requests from browser user clients, defined in "application/x-www-form-urlencoded" in [URL]). The Content-Length fields have been omitted for brevity.
A.1. 単純な~query
~redirectされない単純な~query： ◎ Below is a simple query with a direct response:
QUERY /contacts HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
対する応答： ◎ Response:
HTTP/1.1 200 OK
Content-Type: application/json
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
A.2. `QUERY^m ~supportの発見
`OPTIONS$m ~methodは、 `QUERY^m 用の~supportを発見するための単純な仕方を供する： ◎ A simple way to discover support for QUERY is provided by the OPTIONS (Section 9.3.7 of [HTTP]) method:
OPTIONS /contacts HTTP/1.1 Host: example.org
対する応答： ◎ Response:
HTTP/1.1 200 OK Allow: GET, QUERY, OPTIONS, HEAD
応答の `Allow$h ~fieldは、 指定された資源が~supportする~methodたちが成す集合を指示する。 ◎ The Allow response field (Section 10.2.1 of [HTTP]) denotes the set of supported methods on the specified resource.
`OPTIONS$m の利用に対する代替もある。 一例として、 `QUERY^m 要請は，~server~supportの知識がなくとも試行できる。 ~serverは、 当の要請に対し［ それを処理する ］ことも［ `状態s~code$ `4xx$st0 — `405$st など — で， `Allow$h ~fieldも内包して応答する ］こともできる。 ◎ There are alternatives to the use of OPTIONS. For instance, a QUERY request can be tried without prior knowledge of server support. The server would then either process the request, or it could respond with a 4xx status such as 405 (Method Not Allowed, Section 15.5.6 of [HTTP]), including the Allow response field.
A.3. `QUERY^m 形式の発見
`QUERY^m 用に~supportされる`~MIME型$の発見は、 `Accept-Query$h 応答~fieldを介してアリになる： ◎ The discovery of supported media types for QUERY is possible via the Accept-Query response field (Section 3):
HEAD /contacts HTTP/1.1 Host: example.org
対する応答： ◎ Response:
HTTP/1.1 200 OK Content-Type: application/xhtml Accept-Query: application/x-www-form-urlencoded, application/sql
応答の `Accept-Query$h が包含することになる~MIME型【！要請~method】は、 ~accessされている資源に依存する。 ◎ Responses to which request methods will contain Accept-Query will depend on the resource being accessed.
`Accept-Query$h の検査に対する代替は、 `QUERY^m 要請を為してから， 対する応答が `4xx$st0 状態s — `415$st など — を伴う事例では，その `Accept$h ~fieldを検分することである： ◎ An alternative to checking Accept-Query would be to make a QUERY request, and then -- in case of a 4xx status such as a 415 response (Unsupported Media Type, Section 15.5.16 of [HTTP]) -- to inspect the Accept response field (Section 12.5.1 of [HTTP]):
HTTP/1.1 415 Unsupported Media Type Content-Type: application/xhtml Accept: application/x-www-form-urlencoded, application/sql
A.4. `Content-Location^h, `Location^h, ~redirectされる応答
`2.3＠#content-location§, `2.4＠#location§にて述べたとおり、 `QUERY^m 要請に対する成功裡な【！success】応答（ `2xx$st0 ）内の［ `Content-Location$h, `Location$h ］~fieldは， `GET$m 要請に対し応答することになる代替-資源 — ［ 応答~内に受信した結果 ］あるいは［ 同じ演算を遂行する未来の要請 ］用の資源 — を識別する仕方を供する。 `A.1＠#example.simple§の例と同じ要請： ◎ As described in Sections 2.3 and 2.4, the Content-Location and Location response fields in success responses (2xx, Section 15.3 of [HTTP]) provide a way to identify alternate resources that will respond to GET requests, either for the received result of the request or for future requests to perform the same operation. Going back to the example from Appendix A.1:
QUERY /contacts HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
対する応答： ◎ Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42
Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
Date: Sun, 17 Nov 2024, 16:10:24 GMT
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
A.4.1. `Content-Location^h の利用-法
`Content-Location$h 応答~fieldは、 当の応答の結果を保持している資源を識別する。 ◎ The Content-Location response field received above identifies a resource holding the result for the QUERY response it appeared on:
`A.4§の応答~内に出現したそれへの `GET^m 要請：
GET /contacts/stored-results/17 HTTP/1.1 Host: example.org Accept: application/json
対する応答： ◎ Response:
HTTP/1.1 200 OK
Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
Date: Sun, 17 Nov 2024, 16:10:25 GMT
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
~serverが，この資源を不定期に実装することは、 保証されないことに注意。 なので，~clientは、 ~error応答の後に新たな［ 代替な所在 ］を得するためには， 元の `QUERY^m 要請を再び為す必要がある。 ◎ Note that there is no guarantee that the server will implement this resource indefinitely, so, after an error response, the client would need to redo the original QUERY request in order to obtain a new alternative location.
A.4.2. `Location^h の利用-法
`Location$h 応答~fieldは、 `GET$m に対し，次で応答することになる資源を識別する ⇒ 元の `QUERY^m 要請と同じ処理nに同じ~parameterを与えたとするときの現在の結果 ◎ The Location response field identifies a resource that will respond to GET with a current result for the same process and parameters as the original QUERY request.
`A.4§の応答~内に出現したそれへの `GET^m 要請：
GET /contacts/stored-queries/42 HTTP/1.1 Host: example.org Accept: application/json
この例では、 対する応答は，［ `Last-Modified$h ~fieldが指示する日付 `2024-11-17T16:12:01Z^c にて， 1 個の~entryが除去された ］ため， 2 個の~entryしか包含していない： ◎ In this example, one entry was removed at 2024-11-17T16:12:01Z (as indicated in the Last-Modified field), so the response only contains two entries:
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Sun, 17 November 2024, 16:12:01 GMT
ETag: "42-1"
Date: Sun, 17 Nov 2024, 16:13:17 GMT
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
次を伴う後続な条件付き `GET$m 要請： ◎ ↓ Assuming that the server still exposes the resource and that there was no change in the query result,＼ a subsequent conditional GET request with the following:
If-None-Match: "42-1"
による結果は、［ 当の~serverは、 依然として当の資源を公開する ］かつ［ 当の~queryに対する結果が以前の時点から変化していない ］と見做すなら， `304$st 応答になる。 ◎ would result in a 304 (Not Modified) response (Section 15.4.5 of [HTTP]).
A.4.3. ~redirectされる応答
~serverは、 `状態s~code$ `303$st を利用して，`~redirectされる応答＠#redirection$を送信できる。 ◎ Servers can send "indirect" responses (Section 2.5) using the status code 303 (See Other, Section 15.4.4 of [HTTP]).
`A.4§の要請に対しては、 ~serverは，次で応答するかもしれない： ◎ Given the request at the beginning of Appendix A.4, a server might respond with:
HTTP/1.1 303 See Other Content-Type: text/plain Date: Sun, 17 Nov 2024, 16:13:17 GMT Location: /contacts/stored-queries/42 See stored query at "/contacts/stored-queries/42".
これは、 当の~query用に返される結果【すなわち，応答の`内容$】が無いことを除いて， ~redirectされない応答に `Location$h を内包することに類似する。 これは、 代替な資源しか［ `生成-$しない／再利用しない ］ことを~serverに許容する。 この資源は、 `A.4.2＠#example.location§にて示したとおり利用することもできる。 ◎ This is similar to including Location on a direct response, except that no result for the query is returned. This allows the server to only generate or reuse an alternative resource. This resource could then be used as shown in Appendix A.4.2.
A.5. 条件付き要請
次のような資源を考える： ◎ Consider a resource＼
- `QUERY^m を実装している ◎ implementing QUERY＼
- 要請の`~MIME型$として［ "`application/sql^c" （~SQL）, "`application/xslt+xml^c" （~XSLT `XSLT$r ） ］を~supportする ◎ that supports "application/sql" and "application/xslt+xml" [XSLT] as request media types,＼
- 対する応答の`~MIME型$を "`text/csv^c" として生成し得る。 ◎ and which can generate responses as "text/csv".＼
- ~queryされる~data集合は、 ~RFC文書~情報を包含する。 ◎ The data set being queried contains RFC document information,＼
`QUERY^m 要請 — 当の資源は、 この~queryに対し， 10 年ごとに~group化された情報を返すとする： ◎ and the query returns information grouped by decade:
QUERY /rfc-index.xml HTTP/1.1 Host: example.org Date: Sun, 7 Sep 2025, 00:00:00 GMT Content-Type: application/xslt+xml Accept: text/csv ... ~XSLTを利用している~query内容 ...
対する応答： ◎ Response:
HTTP/1.1 200 OK Date: Sun, 7 Sep 2025, 00:00:00 GMT Location: /stored-queries/4815162342 Content-Type: text/csv Accept-Query: "application/sql", "application/xslt+xml" Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Encoding, Content-Type decade, total, with errata, % with errata, average page count 1960, 26, 5, 19.2, 5.3 1970, 666, 18, 2.7, 6.1 1980, 376, 44, 11.7, 23.4 1990, 1593, 269, 16.9, 25.5 2000, 2888, 1048, 36.3, 27.3 2010, 2954, 895, 30.3, 26.1 2020, 1133, 230, 20.3, 26.2
ここでは、 ~serverは， `GET$m を伴う後続な利用~用に`等価な資源$に~path "`/stored-queries/4815162342^c" をアテガった（`2.4＠#location§）。 ◎ Here, the server has assigned the path "/stored-queries/4815162342" to the equivalent resource (Section 2.4) for subsequent use with GET.
~clientは、 後で同じ~queryを繰返すが，［ 状態が変化したときに限り，結果が返されるべきである ］ものと指定する： ◎ Later on, the client repeats the query, but specifies that results should only be returned when changed:
QUERY /rfc-index.xml HTTP/1.1 Host: example.org Date: Mon, 8, Sep 2025, 11:00:00 GMT Content-Type: application/sql Accept: text/csv If-Modified-Since: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Type ... 同じ~queryだが，~SQLを利用している ...
~queryされている~dataが変化しなかったなら、 ~serverは，次で応答する： ◎ The data being queried did not change, therefore the server responds with:
HTTP/1.1 304 Not Modified Date: Mon, 8 Sep 2025, 11:00:00 GMT Content-Type: text/csv Location: /stored-queries/4815162342 Accept-Query: "application/sql", "application/xslt+xml" Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Type
~serverは、 `GET$m で~accessし得る`等価な資源$用の~URIを識別した。 これにより、 ~clientは，~query要請の内容を送信し直さずに済むようになる： ◎ As the server identified a URI for the equivalent resource, that resource can be accessed with GET. In particular, this avoids resending the query request's content:
GET /stored-queries/4815162342 HTTP/1.1 Host: example.org Date: Sun, 21, Sep 2025, 12:08:00 GMT Accept: text/csv If-Modified-Since: Sun, 31 Aug 2025, 00:00:00 GMT
~data集合の状態が~~実際に変化したとするなら、 新たな内容が返される： ◎ Here, the state of the data set indeed changed, so new content is returned:
HTTP/1.1 200 OK Date: Sun, 21, Sep 2025, 12:08:00 GMT Content-Type: text/csv Last-Modified: Thu, 18 Sep 2025, 19:56:00 GMT Vary: Accept-Query, Content-Encoding, Content-Type decade, total, with errata, % with errata, average page count 1960, 26, 5, 19.2, 5.3 1970, 666, 18, 2.7, 6.1 1980, 376, 44, 11.7, 23.4 1990, 1593, 269, 16.9, 25.5 2000, 2888, 1048, 36.3, 27.3 2010, 2954, 895, 30.3, 26.1 2020, 1133, 230, 20.3, 26.2
（注記： この変化は、 この 10年（ `2020^c ）における~row内にある。 【と記されているが，応答の内容に反映されていない。】） ◎ (Note the change in the row for this decade.)
以下の各~図式は、 条件付き要請の利用, および［ `等価な資源$に ある~URIがアテガわれた（かつ~clientがその利点をとっている）とき， どう相違するか ］を~~説明する。 デモ目的~用に，架空の~field名 `Validator^h が【`検証子~field$として】利用される。 ◎ The diagrams below illustrate the use of conditional requests and how they can differ when a URI is assigned to the equivalent resource (and when the client is taking advantage of it). The fictitious field name "Validator" is used for demonstration purposes.
A.6. 別の~query形式
次の例は、 ~JSON `RFC8259$r 化された~RFC正誤表~databaseに対する要請を示す。 ◎ The following examples show requests on a JSON-shaped ([RFC8259]) database of RFC errata.
次の要請は、 ~XSLT `XSLT$r を利用して［ 年ごと, 定義-済みな正誤表~種別ごと ］に要約された正誤表~情報を抽出する。 ◎ The request below uses eXtensible Stylesheet Language Transformations (XSLT) to extract errata information summarized per year and the defined errata types.
QUERY /errata.json HTTP/1.1
Host: example.org
Content-Type: application/xslt+xml
Accept: application/xml, text/csv
<transform xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:j="http://www.w3.org/2005/xpath-functions"
version="3.0">
<output method="text"/>
<param name="input"/>
<variable name="json"
select="json-to-xml(unparsed-text($input))"/>
<variable name="sc">errata_status_code</variable>
<variable name="sd">submit_date</variable>
<template match="/">
<text>year, total, rejected, verified, hdu, reported</text>
<text> </text>
<variable name="en" select="$json//j:map"/>
<for-each-group select="$en"
group-by="substring-before(j:string[@key=$sd],'-')">
<sort select="current-grouping-key()"/>
<variable name="year" select="current-grouping-key()"/>
<variable name="errata" select=
"$en[$year=substring-before(j:string[@key=$sd],'-')]"/>
<value-of select="concat(
$year,
', ',
count($errata),
', ',
count($errata['Rejected'=j:string[@key=$sc]]),
', ',
count($errata['Verified'=j:string[@key=$sc]]),
', ',
count(
$errata['Held for Document Update'=j:string[@key=$sc]]),
', ',
count($errata['Reported'=j:string[@key=$sc]]),
' ')"/>
</for-each-group>
</template>
</transform>
対する応答： ◎ Response:
HTTP/1.1 200 OK Content-Type: text/csv Accept-Query: "application/jsonpath", "application/xslt+xml" Date: Wed, 19 Feb 2025, 17:10:01 GMT year, total, rejected, verified, hdu, reported 2000, 14, 0, 14, 0, 0 2001, 72, 1, 70, 1, 0 2002, 124, 8, 104, 12, 0 2003, 63, 0, 61, 2, 0 2004, 89, 1, 83, 5, 0 2005, 156, 10, 96, 50, 0 2006, 444, 54, 176, 214, 0 2007, 429, 48, 188, 193, 0 2008, 423, 52, 165, 206, 0 2009, 331, 39, 148, 144, 0 2010, 538, 80, 232, 222, 4 2011, 367, 47, 170, 150, 0 2012, 348, 54, 149, 145, 0 2013, 341, 61, 169, 106, 5 2014, 342, 73, 180, 72, 17 2015, 343, 79, 145, 89, 30 2016, 295, 46, 122, 82, 45 2017, 303, 46, 120, 84, 53 2018, 350, 61, 118, 98, 73 2019, 335, 47, 131, 94, 63 2020, 387, 68, 117, 123, 79 2021, 321, 44, 148, 63, 66 2022, 358, 37, 198, 40, 83 2023, 262, 38, 121, 33, 70 2024, 322, 33, 125, 23, 141 9999, 1, 0, 0, 1, 0
応答の `Accept-Query$h ~fieldは、［ 別の~query形式として `JSONPath^cite `RFC9535$r も~supportされる ］ことを指示していることに注意。 【その形式を利用する】次の要請は、 2024年以降に提出された正誤表のうち，却下されたもの【種別 "`Rejected^c" 】すべての識別子を報告することになろう： ◎ Note the Accept-Query response field indicating that another query format, JSONPath [RFC9535], is supported as well. The request below would report the identifiers of all rejected errata submitted since 2024:
QUERY /errata.json HTTP/1.1
Host: example.org
Content-Type: application/jsonpath
Accept: application/json
$..[
?@.errata_status_code=="Rejected"
&& @.submit_date>"2024"
]
["doc-id"]
対する応答： ◎ Response:
HTTP/1.1 200 OK Content-Type: application/json Accept-Query: "application/jsonpath", "application/xslt+xml" Date: Thu, 20 Feb 2025, 09:55:42 GMT Last-Modified: Thu, 20 Feb 2025 06:10:01 GMT [ "RFC1185","RFC8407","RFC6350","RFC8467","RFC1157","RFC9543", "RFC9076","RFC7656","RFC2822","RFC9460","RFC2104","RFC6797", "RFC9499","RFC9557","RFC2131","RFC2328","RFC9001","RFC3325", "RFC9438","RFC2526","RFC2985","RFC7643","RFC9132","RFC6376", "RFC9110","RFC9460","RFC7748","RFC9497","RFC8463","RFC4035", "RFC7239","RFC9083","RFC9537","RFC9537","RFC9420","RFC9000", "RFC9656","RFC9110","RFC2324","RFC2549","RFC6797","RFC2549", "RFC8894" ]
付録 B. ~method名 `QUERY^m の選定
`~HTTP~method~registry＠~IANA-a/http-methods$cite は、 `安全$かつ`冪等$な特質を伴う他の~methodとして，次に挙げるものを すでに包含する ⇒＃ `PROPFIND^m `RFC4918$r, `REPORT^m `RFC3253$r, `SEARCH^m `RFC5323$r ◎ The "Hypertext Transfer Protocol (HTTP) Method Registry" (<http://www.iana.org/assignments/http-methods>) already contains three other methods with the properties "safe" and "idempotent": "PROPFIND" [RFC4918], "REPORT" [RFC3253], and "SEARCH" [RFC5323].
これらを［ この仕様が新たな~method `QUERY^m として定義するものと合致する仕方で更新する ］ことにより再利用することもアリであった。 ~~実際、 この仕様の早期~段階では， `SEARCH^m を利用した。 ◎ It would have been possible to reuse any of these, updating it in a way that it matches what this specification defines as the new method "QUERY". Indeed, the early stages of this specification used "SEARCH".
~method名として最終的に `QUERY^m が選ばれたわけは： ◎ The method name "QUERY" ultimately was chosen because:
- 上に挙げた代替は， 要請の`内容$用に汎用な`~MIME型$（ "`application/xml^c" ）を利用するので、 当の要請の意味論は，もっぱら その内容に依存する。 ◎ The alternatives use a generic media type for the request content ("application/xml"); the semantics of the request depend solely on the request content.
- 上に挙げた代替は、 いずれも~WebDAVの活動に端を発する — 多くの者は、 そのことにより，それらの再利用について~~否定的にも感じている。 ◎ Furthermore, they all originate from the WebDAV activity, about which many have mixed feelings.
- `QUERY^m は、 ~URIの~query成分との関係も捕捉する。 ◎ "QUERY" captures the relation with the URI's query component well.
謝辞
様々な［ 案／考査／~feedback ］を寄せられた~HTTP~WGの~memberすべてに。 ◎ We thank all members of the HTTP Working Group for their ideas, reviews, and feedback.
次に挙げる各個人には、 特に感謝する： ◎ The following individuals deserve special recognition:＼
貢献者
`Ashok Malhotra^en 氏は、 早期から論に参加して，この仕様を導いた。 ◎ Ashok Malhotra participated in early discussions leading to this specification: ◎ Ashok Malhotra Email: malhotrasahib@gmail.com
`Asbjørn Ulsberg^en 氏は、 2019年における `HTTP Workshop^en の間に， この~HTTP~methodに対する論を~~再開した。 ◎ Discussion on this HTTP method was reopened by Asbjørn Ulsberg during the HTTP Workshop in 2019: ◎ Asbjørn Ulsberg Email: asbjorn@ulsberg.no URI: https://asbjor.nu/