[5] Authorization:
ヘッダーは、
HTTP認証のためのクライアントの credentials を指定するものです。
[6] Authorization:
ヘッダーは、
利用者エージェントが起源鯖において認証するためのもので、
要求されている資源の保護空間における利用者エージェントの認証情報を含む
credentials を指定するものです >>3。
[410] Authorization:
ヘッダーの値は credentials です
>>3, >>409, >>413。
[34]
なぜか Authorization
で独自の構文を採用するWebサービスが多々あります。
鍵
[35] API guide — CKAN 2.10.4 documentation, , https://docs.ckan.org/en/2.10/api/index.html#authentication-and-api-tokens
名前:鍵
key=鍵
[421] GCM HTTP Connection Server | Android Developers ( ( 版)) https://developer.android.com/google/gcm/http.html
[7] Authorization:
ヘッダーは通常
401
応答を受け取った後の要求で使いますが、
必ずしもそうでなくても構いません >>3。
[48] 通常 Webブラウザーは 401
応答を受け取った後に認証のための情報を利用者に求めるダイアログボックスを表示し、
そこで入力された情報を用いて再度 Authorization:
ヘッダー付きの要求を繰り返すことによって認証の通過を試みます。
[402] しかし最初から Authorization:
ヘッダー付きで要求を送ることも認められています。
例えば Webブラウザーは以前利用者が入力した認証のための情報を記録しておき、
以後それを自動的に使うことがあります。また、Webブラウザー以外の利用者エージェントは、
実行時の引数などから予め認証のための情報を受けとっておき、要求送信時にいきなりそれを使うように実装されていることもあります。
[403] Authorization:
欄付きの要求に対し、起源鯖はそれを使って認証できない場合に
401
応答を返すべきです
>>407, >>416。
Authorization:
欄付きの要求に対し、
起源鯖はそれを受け付ける意思が (今後も)
ない場合、 403
応答を返すことができるとされていました >>405。
RFC 2068 にはこの用法は明記されていません。[406] プロキシは、要求の Authorization:
ヘッダーを変更してはなりません >>3, >>405, >>408, >>417, >>24。
[2] Authorization:
ヘッダーの有無は応答をキャッシュに蓄積できるかに影響します。
Authorization:
を使わない credentials の指定[17] credentials は Authorization:
以外によって指定することも禁止されてはいません
>>16 が、 Authorization:
は自動的に
Cache-Control: private
のような効果を持つ
(キャッシュ可能性参照。) のに対し、それ以外の方法では自動的にはキャッシュが禁止されませんから、
要求または応答の Cache-Control:
ヘッダーで明示的にキャッシュを制御する必要が生じます。
[11] WSSE では Authorization:
ヘッダーは指定しないか形式的に指定するだけで、
実際の credentials は X-WSSE:
ヘッダーに指定することとなっています。
[1] OAuth 1.0 では credentials を要求のAuthorization:
ヘッダーに指定することもできますが、
要求URLの query に指定したり、
application/x-www-form-urlencoded
な payload body
に含めたりもできます。
[29] OAuth 2.0 bearer は要求の
Authorization:
ヘッダーに指定することもできますが、
要求URLの query に指定したり、
application/x-www-form-urlencoded
な payload body
に含めたりもできます。
Bearer
[32] 各種 Webサービスの提供する Web API は、 自社サービス専用の独自の方法 (独自の HTTPヘッダー、 独自の query parameter など) を使った指定方法を定めていることが、 割とよくあります。
[33] 歴史的経緯 (21世紀初頭からサービスを続けているとか) を除けば、 そのような標準的でない方法を採用するメリットは皆無に等しいです。 新しいサービスがそのような手法を採っているとしたら、 HTTP に詳しくない人が設計した可能性を疑わざるを得ません。
[25] 応答で challenge を指定する
WWW-Authenticate:
ヘッダーと似ています。
[422] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#page-14
[419] IRC logs: freenode / #whatwg / 20130506 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130506
[420] Re: Re: Re: Fetch: HTTP authentication and CORS ( (Hallvord Reiar Michaelsen Steen 著, 版)) http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0522.html
[26] Fix #198: give precedence to custom Authorization headers · whatwg/fetch@9b18866 ( 版) https://github.com/whatwg/fetch/commit/9b188662ab3d0319fe6e5fc10f034a9f10f7b069
[31] SafariはBasic認証の結果でAuthorization: Bearerを上書きする - Qiita () https://qiita.com/ksakiyama134/items/efad0e48464e0f501d76