LoginSignup
1
1

More than 3 years have passed since last update.

HTTPのリクエストヘッダーでタイムアウトを操作できない

Posted at

まとめ

  • リクエストのタイムアウト制御はリクエストを送るサーバー、メソッドの責任?
  • TimeOutというヘッダーがあるが、それを遵守する責務はない
  • そもそもTimeOutヘッダーはHTTPメソッド1のLOCKリクエストに使用するものであり、通常は使用しない

疑問

HTTPでGETやPOSTするときに、
リクエスト先に到達できなかったり処理に時間がかかる場合に、リクエストにタイムアウトを設定したい。
リクエストに対する設定なので、HTTPのリクエストヘッダーで設定できないか?

(ヘッダーは自由に記述できるが送信機能に手を加えられない場合がある)

観測として、一部のネット上の記事でTimeOutヘッダーを付与しているものを確認しているので、これを使えないか?

HTTPヘッダーの確認

HTTP ヘッダー - HTTP | MDN

'X-' 接頭辞を使用して独自のヘッダーを追加できますが、この慣習は 2012 年 6 月に非推奨になりました。これは、 RFC 6648 で非標準のフィールドが標準になったときに発生した不便さのためです。それ以外のヘッダーは IANA レジストリ に収録されており、その基になったものは RFC 4229 です。また IANA は 新たに提案された HTTP ヘッダーのレジストリ も管理しています。

とあるのでIANA レジストリ を参照する

Message Headers

Header Field Name Template Protocol Status Reference
Timeout http standard [RFC4918]

それらしいTimeOutヘッダーを確認。

RFC4918を参照

RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)#section-10.7

10.7. Timeout Request Header

  TimeOut = "Timeout" ":" 1#TimeType
  TimeType = ("Second-" DAVTimeOutVal | "Infinite")
             ; No LWS allowed within TimeType
  DAVTimeOutVal = 1*DIGIT

Clients MAY include Timeout request headers in their LOCK requests.
However, the server is not required to honor or even consider these
requests. Clients MUST NOT submit a Timeout request header with any
method other than a LOCK method.

The "Second" TimeType specifies the number of seconds that will
elapse between granting of the lock at the server, and the automatic
removal of the lock. The timeout value for TimeType "Second" MUST
NOT be greater than 2^32-1.

See Section 6.6 for a description of lock timeout behavior.

機械翻訳と別途部分機械翻訳

RFC4918 日本語訳 - [RFC/技術資料] ぺんたん info

クライアントは、LOCK要求にタイムアウト要求ヘッダーを含めることができます。
ただし、サーバーはこれらを尊重することも考慮する必要もありません。
リクエスト。 クライアントは、タイムアウト要求ヘッダーを送信しないでください。
LOCKメソッド以外のメソッド。

ちょっと後半の翻訳がイマイチですが、つまり

LOCK要求(LOCK requests.)に使ってください。
LOCKメソッド以外に使わないでください(Clients MUST NOT submit a Timeout request header with any
method other than a LOCK method)

そして
ただし、サーバーはこれらを尊重することも考慮する必要もありません。

送ったとしてそれが守られるとは限らないと読みました。

LOCK methodとはなんぞや

GETにPOSTにCRUDプラスあれやこれやはわかりますが、LOCKは知らなかったので調査。

"svn lock"で"400 Bad Request"が返ってくる - kakakakakku blog

access.log
127.0.0.1 - kakku22 [24/Jan/2013:20:41:25 +0900] "LOCK /svn/trunk/Hello.txt HTTP/1.1" 400 226

WebDAV時代のセキュリティ対策[前編](1/4)

LOCK コレクションを含むリソースのロック

というわけでリソースに対する処理であり、通常のGETやPOSTとは違うということはわかりますね。

GETのように扱えないし、そもそも守ってもらえないわけです。

というわけで

HTTPヘッダーだけでは制御できず、どうしても
XMLHttpRequest.timeout - Web API | MDN
のようにリクエスト側の機能として実装されているものを使う必要があるように見受けられました。

レスポンスのデータの寿命やキャッシュにはかなりヘッダーが絡んでくるので、リクエストの制御も出来るかなと思ったのですが、
ここだけ扱えなくてとても困っております。


  1. GETとかPOST 

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1