Edit

Page

Page title:

Page body:

[8] [DFN[[RUBYB[[[要求]]]@en[request]]]]は、[[クライアント]]から[[鯖]]に対して送信される、
[[クライアント]]が希望する処理を記述した[[HTTPメッセージ]]です。

[9] [[要求メッセージ]]は、[[HTTP接続]]上のバイト列として転送されます。
[[鯖]]は[[要求メッセージ]]を受信すると、その記述に従って処理を実行し、
結果を[[応答メッセージ]]として返すことが期待されています。

* 仕様書

[REFS[
- [2] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.3.1>
- [4] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.3.2>
- [5] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-5.5>
- [17] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-8.1>
]REFS]

* 構文

[10] [[要求メッセージ]]の[[先頭行]]は、[[要求行]]と呼ばれており、
[[要求メソッド]]、[[要求URL]]、[[プロトコルの版]]を指定します。

[11] [[先頭行]]の後には[[要求ヘッダー]]と[[メッセージ本体]]が続きます。

[FIG(railroad)[
= [[要求行]]
= *
== [[要求ヘッダー]]
= 空行
= [[メッセージ本体]]
]FIG]

;; [12] 詳しくは [[HTTPメッセージ]]を参照してください。

[13] [[要求メッセージ]]における[[ヘッダー]]や[[メッセージ本体]]の構文や意味は、
[[要求メソッド]]によって決まります。詳しくは各[[要求メソッド]]の項を参照してください。

* 文脈

[19] [[HTTP/0.9]] と [[HTTP/1.0]] と [[HTTP/1.1]] では、
[[クライアント]]は[[HTTP接続]]を確立したら、
[[要求]]を送信できます。

[20] [[HTTP/1.0]] と [[HTTP/1.1]] で[[接続]]が閉じられていないなら、
前の[[要求]]を送り次第、次の[[要求]]を送ることができます。

;; [[HTTP接続]]や[[HTTPパイプライン]]も参照。

[21] [[HTTP/2]] では[[接続序文]]の送信後に[[クライアント]]は[[要求]]を送信できます。

[18] [[HTTP/2]] では、[[クライアント]]は新しい[[ストリーム]]で[[要求]]を送信することができます
[SRC[>>17]]。

;; [[HTTPメッセージ]]も参照。

[24] [[IE]] も [[Firefox]] も [[Chrome]] も、[[要求]]の送信完了前に[[応答]]の受信を完了したとしても、
そのことを理由に[[要求]]の送信を中断することはないようです。 [TIME[2015-08-02T15:06:06.400Z]]

* 分類

[14] [[要求メッセージ]]は、主として[[要求メソッド]]によって分類されます。

[EG[
[15] 例えば「[CODE(HTTP)@en[[[GET]]]] [[要求]]」は、[[要求行]]の[[要求メソッド]]が
[CODE(HTTP)@en[[[GET]]]] である[[要求]]のことをいいます。
]EG]

[16] 他に次のような分類があります。
[FIG(list short)[
- [[条件付き要求]]
- [[範囲要求]]
- [[同一起源要求]]
- [[交差起源要求]]
]FIG]

* 再試行

[22] [[HTTP接続]]を参照。

* [CODE(MIME)@en[msgtype]] の値 [CODE(MIME)@en[request]] (MIME)

[3] [[MIME型]] [CODE(MIME)@en[[[message/http]]]], [CODE(MIME)@en[[[application/http]]]]
の [CODE(MIME)@en[[[msgtype]]]]
[[引数]]の値 [DFN[[CODE(MIME)@en[[[request]]]]]] [SRC[>>2, >>4]] は、
[[要求]]を表します。

* 要求文脈

[6] 次の[[ヘッダー]]は、[DFN[[RUBYB[[[要求文脈]]]@en[request context]]]]を提供するものと分類されています
[SRC[>>5]]。
[FIG(list short)[
- [CODE(HTTP)@en[[[From:]]]]
- [CODE(HTTP)@en[[[Referer:]]]]
- [CODE(HTTP)@en[[[User-Agent:]]]]
]FIG]

* 状態

[23] [CODE(DOMi)@en[Request]] [[オブジェクト]]は、次の情報を持ちます。

[FIG(list members)[ [[要求]]
: [F[構文解析器メタデータ]] :
[[構文解析器]]由来の [[fetch]] かどうかのフラグです。
: [F[[[navigation request]] かどうか]] : [[fetch]] の [[UIR]] の判定で使います。
: [F[[[フォームの提出]]かどうか]] : [[fetch]] の [[UIR]] の判定で使います。
: [F[対象閲覧文脈]] : [[fetch]] の [[UIR]] の判定で使います。
: [F[reload-navigation flag]] : [[再読込]]かどうかのフラグです。
: [F[履歴ナビゲーションフラグ]] : [[履歴の探索]]かどうかのフラグです。
: [F[クライアント][要求クライアント]] :
: [F[参照元]] : 
: [F[参照元ポリシー]] :
: [F[クライアント][要求クライアント]] :
: [F[予約クライアント]] :
: [F[対象クライアントID]] :
: [F[窓][要求の窓]] :  
: [F[混合内容][Mixed Content]] :

]FIG]

* メンバー

[FIG(short list)[ [46] [CODE[Request]] [[インターフェイス]]の[[メンバー][インターフェイスメンバー]]
- [CODE(DOMa)@en[isReloadNavigation]]
- [CODE[isHistoryNavigation]]
]FIG]

* 歴史

[FIG(quote)[
[FIGCAPTION[
[1] RFC 1945 (HTTP/1.0) 5.; RFC 2068・2616 (HTTP/1.1) 5 Request
]FIGCAPTION]

> A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use. [DEL[[INS[{1945}]] For backwards compatibility with the more limited HTTP/0.9 protocol, there are two valid formats for an HTTP request:]]

[[クライアント]]から[[サーバー]]への[DFN[要求メッセージ]]は、
そのメッセージの最初の行に、その[[資源]]に適用する[[方式]],
その資源の識別子, 使用するプロトコルの版を含めます。[DEL[より限定された HTTP/0.9 プロトコルとの後方互換性のために、 HTTP 要求には2つの妥当な書式があります。]]

[DEL[
[DEL[
>[INS[{1945}]]
-       Request        = Simple-Request | Full-Request
>
-       Simple-Request = "GET" SP Request-URI CRLF
>
-
[PRE[
       Full-Request   = Request-Line             ; Section 5.1
                        *( General-Header        ; Section 4.3
                         | Request-Header        ; Section 5.2
                         | Entity-Header )       ; Section 7.1
                        CRLF
                        [ Entity-Body ]          ; Section 7.2
]PRE]
]DEL]
[INS[
>[INS[{2068}]]
-
[PRE[
           Request       = Request-Line              ; Section 5.1
                           *( general-header         ; Section 4.5
                            | request-header         ; Section 5.3
                            | entity-header )        ; Section 7.1
                           CRLF
                           [ message-body ]          ; Section 7.2
]PRE]
]INS]
]DEL]
[INS[
>[INS[{2616}]]
-
[PRE[
        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3
]PRE]
]INS]

[DEL[
>[INS[{1945}]] If an HTTP/1.0 server receives a Simple-Request, it must respond with
an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving
a Full-Response should never generate a Simple-Request.

HTTP/1.0 サーバーが [CODE(ABNF)[Simple-Request]] を受信したら、
HTTP/0.9 [CODE(ABNF)[Simple-Response]] で応答しなければなりません。
[CODE(ABNF)[Full-Response]] を受信する能力のある HTTP/1.0
クライアントは決して [CODE(ABNF)[Simple-Request]] を生成するべきではありません。
]DEL]

*** 5.1 Request-Line
→[CODE(WikiPage)[[[Request-Line]]]]
*** RFC 2068・2616 5.2 The Resource Identified by a Request
→[CODE(WikiPage)[[[Request-URI]]]]
*** RFC 1945 5.2; RFC 2068・2616 5.3 Request Header Fields
→[CODE(WikiPage)[[[要求頭欄]]]]
]FIG]

[FIG(quote)[
[FIGCAPTION[
[7] RFC 2616 5 Request
]FIGCAPTION]

A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use.

顧客からサーバーへの要求メッセージはそのメッセージの最初の行に
資源に対して適用される方式と資源の識別子, 使われるプロトコルの版を
含みます。

Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

*5.1 Request-Line

The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF is allowed
except in the final CRLF sequence.

Request-Line は方式字句で始まり、 Request-URI とプロトコルの版が
続き、 CRLF で終わります。各要素は SP 文字で区切ります。
最後の CRLF 列以外で CR や LF は認められません。

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

***5.1.1 Method

The Method  token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.

Method 字句は Request-URI で識別される資源に行われる方式を示します。
方式は大文字・小文字を区別しません。

;; 方式 = method。直訳。改訳きぼんぬ。

Method         = "OPTIONS"                ; Section 9.2
                      | "GET"                    ; Section 9.3
                      | "HEAD"                   ; Section 9.4
                      | "POST"                   ; Section 9.5
                      | "PUT"                    ; Section 9.6
                      | "DELETE"                 ; Section 9.7
                      | "TRACE"                  ; Section 9.8
                      | "CONNECT"                ; Section 9.9
                      | extension-method
       extension-method = token

The list of methods allowed by a resource can be specified in an
   Allow header field (section 14.7). The return code of the response
   always notifies the client whether a method is currently allowed on a
   resource, since the set of allowed methods can change dynamically. An
   origin server SHOULD return the status code 405 (Method Not Allowed)
   if the method is known by the origin server but not allowed for the
   requested resource, and 501 (Not Implemented) if the method is
   unrecognized or not implemented by the origin server. The methods GET
   and HEAD MUST be supported by all general-purpose servers. All other
   methods are OPTIONAL; however, if the above methods are implemented,
   they MUST be implemented with the same semantics as those specified
   in section 9.

ある資源に対して認められる方式の表は Allow 頭欄で指定出来ます。
応答の復帰符号は常に顧客に方式が現在資源に認められているかを知らせます。
というのは認められる方式の集合は動的に変化するのです。
また元のサーバーは、状態符号 405 (方式は認められていません)
を方式は知っているが要求された資源に認めていない場合に、
501 (未実装) を方式が認識できないか実装されていない場合に返す
'''べきです'''。方式 GET および HEAD は全ての常用サーバーが
対応し'''なければなりません'''。他の全ての方式は'''任意です'''。
しかし、上記の方式が実装されている場合、第9章で規定するのと
同じ意味で実装し'''なければなりません'''。
***5.1.2 Request-URI

The Request-URI is a Uniform Resource Identifier (section 3.2) and
identifies the resource upon which to apply the request.

Request-URI は統一資源識別子であり、要求が適用される資源を識別します。

Request-URI    = "*" | absoluteURI | abs_path | authority

The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One
example would be

要求の性質により4つの選択肢が Request-URI にはあります。星印 "*"
は要求が特定の資源に対するものではなく、サーバー自身に対するものである
ことを示し、使われる方式が資源に適用される必要がない時にだけ
認められます。1つの例はこれです。

OPTIONS * HTTP/1.1

The absoluteURI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server
specified by the absoluteURI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An example
Request-Line would be:

absoluteURI 形式は要求が串に対して行われる場合に'''必須'''です。
串は要求を転送するか妥当な控えから供給するかし、応答を返すように
要求されます。なお、串は要求を他の串に転送しても absoluteURI
で指定されたサーバーに直接転送しても'''構いません'''。
要求 loop  を避けるため、串はそのサーバー名の
全て (別名, 地方変名, 数値 IP アドレスを含む。) 
を認識でき'''なければなりません'''。 Request-Line
の例を示します。

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.

将来の版の HTTP で全ての要求を absoluteURI に移行するのを可能にするため、
全ての HTTP/1.1 サーバーは要求で absoluteURI 形式を受け入れ
'''なければなりません'''。 HTTP/1.1 顧客は串への要求でのみ
これを生成するにも関わらずです。

The authority form is only used by the CONNECT method (section 9.9).

authority 形式は CONNECT 方式でのみ使われます。

The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case the absolute
   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
   the Request-URI, and the network location of the URI (authority) MUST
   be transmitted in a Host header field. For example, a client wishing
   to retrieve the resource above directly from the origin server would
   create a TCP connection to port 80 of the host "www.w3.org" and send
   the lines:

最も良くある形式の Request-URI は源サーバーまたは関門の資源を
識別するのに使います。この場合 URI の絶対経路を Request-URI
とっしてわたさ'''なければなりません''' (3.2.1節, abs_path)。
また URI のネットワーク位置 (authority) は Host 頭欄で渡さ
'''なければなりません'''。例えば、顧客が原サーバーから直接
上の資源を取り出したい時にはホスト「www.w3.org」の80番に
TCP 接続を張って次の行を送ります。

GET /pub/WWW/TheProject.html HTTP/1.1
       Host: www.w3.org

followed by the remainder of the Request. Note that the absolute path
cannot be empty; if none is present in the original URI, it MUST be
given as "/" (the server root).

続けて Request の残りを送ります。なお、絶対経路は空であってはなりません。
源 URI に無い場合は、 "/" (サーバーの根) を与え'''なければなりません'''。

The Request-URI is transmitted in the format specified in section
   3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
   [42], the origin server MUST decode the Request-URI in order to
   properly interpret the request. Servers SHOULD respond to invalid
   Request-URIs with an appropriate status code.

Request-URI は3.2.1節で規定した方式で渡します。 Request-URI
が「% HEX HEX」符号化を使って符号化されている場合、源サーバーは
要求を適切に解釈するために Request-URI を復号し'''なければなりません'''。
サーバーは不正な Request-URI に適切な状態符号で反応する'''べきです'''。

A transparent proxy MUST NOT rewrite the "abs_path" part of the
   received Request-URI when forwarding it to the next inbound server,
   except as noted above to replace a null abs_path with "/".

透過串は受け取った Request-URI を次の上りサーバーに転送する時に、
上に記したとおり abs_path を "/" に書き換えるのを除いては、
"abs_path" 部分を書き換えては'''なりません'''。

Note: The "no rewrite" rule prevents the proxy from changing the
      meaning of the request when the origin server is improperly using
      a non-reserved URI character for a reserved purpose.  Implementors
      should be aware that some pre-HTTP/1.1 proxies have been known to
      rewrite the Request-URI.

参考: 「書き換えない」規則は源サーバーが予約していない
URI 文字をよさ腐れている目的に不適切に使っている時に、
串が要求の意味を替えてしまうことを防ぎます。
実装者は HTTP/1.1 以前の串が Request-URI を書き換えてしまうと
知られていることに注意するべきです。

*5.2 The Resource Identified by a Request [INS[要求により識別される資源]]
>The exact resource identified by an Internet request is determined by
examining both the Request-URI and the Host header field.

Internet 要求により識別される実際の資源は [CODE(ABNF)[Request-URI]]
及び [CODE(HTTO)[Host]] 頭欄の両者の検査により決定します。

>An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see
section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)

資源が要求されたホストと異なっていることを認めない元サーバーは、
HTTP/1.1 要求で識別される資源を決定する時に [CODE(HTTP)[Host]]
頭欄の値を無視しても'''構いません'''。
(HTTP/1.1 における [CODE(HTTP)[HTTP]] への対応の他の要件については
19.6.1.1 を参照。)

>An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host
names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:

ホストの要求に基づく資源が異なっている元サーバー
(時たま仮想ホストとか可変ホスト名とか言われます。) は、 HTTP/1.1
要求で要求される資源の決定に次の規則を用いなければ'''なりません'''。

1. If Request-URI is an absoluteURI, the host is part of the
     Request-URI. Any Host header field value in the request MUST be
     ignored.

Request-URI が [[absoluteURI]] であれば、ホストは Request-URI
の一部です。要求中の Host 頭欄の値は無視しなければ'''なりません'''。

2. If the Request-URI is not an absoluteURI, and the request includes
     a Host header field, the host is determined by the Host header
     field value.

Request-URI が [CODE(ABNF)[absoluiteURI]] ではなく、要求が Host
頭欄が Host 頭欄を含んでいれば、ホストは Host 頭欄の値で決定します。

3. If the host as determined by rule 1 or 2 is not a valid host on
     the server, the response MUST be a 400 (Bad Request) error message.

規則1又は2により決定されたホストがそのサーバーにおいて妥当なホストでなければ、応答は
[[400]] (悪い要求) エラー・メッセージでなければ'''なりません'''。

>Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what
exact resource is being requested.

Host 頭欄の欠けた HTTP/1.1 要求の受信者は試行錯誤
(例えば特定ホストに固有の URI 経路を検査) して要求されている実際の資源を決定しても'''構いません'''。
]FIG]

** Fetch

[25] [CITE[Request constructor and fetch() method, add RedirectResponse named const... · 2e82a88 · whatwg/fetch]]
( ([TIME[2014-05-29 11:05:45 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/2e82a88634f0cd23de1977b11b36d1e907d01f5c>

[26] [CITE[Clean up new Request and fetch() · 97f680c · whatwg/fetch]]
( ([TIME[2014-05-30 02:50:48 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/97f680c318a4b4bdc461ae607f245fe1441b6877>

[27] [CITE[Move method and header related definitions together. Attempt at defining... · 2bd135c · whatwg/fetch]]
( ([TIME[2014-05-31 02:38:25 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/2bd135ce3fec35c4e6ec332c62a6343a94c34f59>

[28] [CITE@en[Introduce the concept of a request window. Fixes #70. Replaces the au… · whatwg/fetch@34231ee]]
([TIME[2015-07-15 12:33:53 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/34231ee8a150b686355f85ef66f1de03be262a5f>

[29] [CITE@en[Introduce a target browsing context concept for MIX and CSP · whatwg/fetch@d015cb8]]
([TIME[2015-09-08 15:14:22 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/d015cb80ccaf05cbeab5aee9dff4c3f43a3b73d4>

[30] [CITE@en[Store a url list for requests and responses so CSP can do the right t… · whatwg/fetch@1d8173a]]
([TIME[2015-06-12 12:17:53 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/1d8173afffcffad2587f2922381878939c9cebea>

[31] [CITE@en[Editorial: remove structured cloning section]]
([[annevk]]著, [TIME[2016-08-10 22:50:02 +09:00]])
<https://github.com/whatwg/fetch/commit/3dc1612fce7ab38673854d0bf26a4e118e52f077>

[32] [CITE@en[Treat data URLs as same-origin]]
([[annevk]]著, [TIME[2016-09-16 02:50:19 +09:00]])
<https://github.com/whatwg/fetch/commit/6f223de29733e64dbe1dfc6028c6e0a4a5d89398>

[33] [CITE@en[Make Request constructor more forgiving]]
([[annevk]]著, [TIME[2016-09-27 18:59:04 +09:00]])
<https://github.com/whatwg/fetch/commit/76578f456797ff675f4f89cb8727bde3954e062c>

[34] [CITE@en[Add request's reserved client and target client id]]
([[jungkees]]著, [TIME[2016-10-24 20:58:40 +09:00]])
<https://github.com/whatwg/fetch/commit/fb87b70df0af3a5e6bc7bb9a91b4dc7eb4924acb>

[35] [CITE@en[Stream-based requests (Request with ReadableStream)]]
([[yutakahirano]]著, [TIME[2017-01-17 16:31:32 +09:00]])
<https://github.com/whatwg/fetch/commit/0c470b5860fe690b1136b0242951f682405103cc>

[36] [CITE@en[Replace skip-service-worker flag with service-workers mode]]
([[jakearchibald]]著, [TIME[2017-02-14 22:07:54 +09:00]])
<https://github.com/whatwg/fetch/commit/d41c2380dc828e7a23c6196a344b42b2d0e9beec>

[37] [CITE@en[Regression fix: make Request constructor account for changes to fill]]
([[annevk]]著, [TIME[2017-09-04 18:04:59 +09:00]])
<https://github.com/whatwg/fetch/commit/9fa071b0698d6c5a8ffc625cf758df3892685477>

[38] [CITE@en[Type confusion in Request constructor leading to underdefined behavior · Issue #483 · whatwg/fetch]]
([TIME[2017-09-05 14:12:10 +09:00]])
<https://github.com/whatwg/fetch/issues/483>

[39] [CITE@en[Constructing a Headers from another Headers is lossy · Issue #481 · whatwg/fetch]]
([TIME[2017-09-05 14:13:36 +09:00]])
<https://github.com/whatwg/fetch/issues/481>

[40] [CITE@en[Regression: make Request constructor account for changes to fill by annevk · Pull Request #484 · whatwg/fetch]]
([TIME[2017-09-05 14:14:01 +09:00]])
<https://github.com/whatwg/fetch/pull/484>

[41] [CITE@en[Allow used body replacement in Request constructor]]
([[harrishancock]]著, [TIME[2018-03-17 15:02:56 +09:00]])
<https://github.com/whatwg/fetch/commit/5b7dae0fcc24cc8e025b216b80248d2619177ac4>

[43] [CITE@en[Inconsistency in Request constructor when rewriting a used body · Issue #674 · whatwg/fetch]]
([TIME[2018-03-18 13:26:09 +09:00]])
<https://github.com/whatwg/fetch/issues/674>

[44] [CITE@en[Allow used body replacement in Request constructor by harrishancock · Pull Request #675 · whatwg/fetch]]
([TIME[2018-03-18 13:26:46 +09:00]])
<https://github.com/whatwg/fetch/pull/675>

[45] [CITE@en[Add Request's isReloadNavigation]]
([[yutakahirano]]著, [TIME[2018-04-27 16:18:54 +09:00]])
<https://github.com/whatwg/fetch/commit/42ae7a160369483ca833bf548712912c7be754a8>

[47] [CITE@en[Introduce reload-navigation flag by yutakahirano · Pull Request #685 · whatwg/fetch]]
([TIME[2018-05-01 14:00:00 +09:00]])
<https://github.com/whatwg/fetch/pull/685>

[48] [CITE@en[Add Request's isHistoryNavigation]]
([[yutakahirano]]著, [TIME[2018-05-29 12:22:11 +09:00]])
<https://github.com/whatwg/fetch/commit/bd9b4e3d14520a41e5c49f3ec9c9c6de0035ce07>

[49] [CITE@en[Align with IDL constructor changes]]
([[autokagami]]著, [TIME[2019-09-24 22:59:53 +09:00]])
<https://github.com/whatwg/fetch/commit/eff7659a2cb15aed801a9dbfc00c58e22efbbd42>

[50] [CITE@en[Add TAO check]]
([[npm1]], [TIME[2019-12-04 19:41:07 +09:00]], [TIME[2022-01-18T11:47:40.000Z]])
<https://github.com/whatwg/fetch/commit/9dd531988b04f4fadd43022a0613a90b42ce46d4>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)