* 仕様書 [REFS[ - [413] '''[CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-01-09 20:55:20 +09:00]] 版) ''' - [416] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) - [417] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) ]REFS] * 構文 [410] [CODE(HTTP)@en[[[Authorization:]]]] 欄の値は [[credentials]] です [SRC[>>409, >>413]]。 * 非 ASCII 文字の扱い [REFS[ - [1] [CITE[Bug 41489 - http authentication does not support non-ASCII characters]] ]REFS] * 文脈 [48] 通常 [[Webブラウザー]]は [CODE(HTTP)@en[[[401]]]] [[応答]]を受け取った後に[[認証]]のための情報を[[利用者]]に求め、 それを用いて再度 [CODE(HTTP)@en[[[Authorization:]]]] 欄付きの[[要求]]を繰り返すことによって[[認証]]の通過を試みます。 [402] しかし最初から [CODE(HTTP)@en[[[Authorization:]]]] 欄付きで[[要求]]を送っても構いません。 例えば [[Webブラウザー]]は以前[[利用者]]が入力した[[認証]]のための情報を記録しておき、 以後それを自動的に使うことがあります。また、[[Webブラウザー]]以外の[[利用者エージェント]]は、 実行時の[[引数]]などから予め[[認証]]のための情報を受けとっておき、[[要求]]送信時にいきなりそれを使うように実装されていることもあります。 * 鯖の処理モデル ** 応答 [403] [CODE(HTTP)@en[[[Authorization:]]]] 欄付きの[[要求]]に対し、[[起源鯖]]はそれを使って[[認証]]できない場合に [CODE(HTTP)[[[401]]]] [[応答]]を返す[['''べきです''']] [SRC[>>407, >>416]]。 ;; [404] [[RFC 1945]] は [CODE(HTTP)@en[[[Authorization:]]]] 欄付きの[[要求]]に対し、 [[起源鯖]]はそれを受け付ける意思が (今後も) ない場合、 [CODE(HTTP)[[[403]]]] [[応答]]を返すことができるとされていました [SRC[>>405]]。 [[RFC 2068]] にはこの用法は明記されていません。 * 串とキャッシュの処理モデル [406] [[串]]は [CODE(HTTP)@en[[[Authorization:]]]] 欄をいじってはなりません [SRC[>>405, >>408, >>417]]。 ** キャッシュ可能性 [47] [[RFC 1945]] では [CODE(HTTP)@en[[[Authorization:]]]] 欄を含む[[応答]]は[[キャッシュ可能]]では''無い''とされていました [SRC[>>46, >>405]]。 [412] [[RFC 2068]] と [[RFC 2616]] では、 [CODE(HTTP)@en[[[Cache-Control:]]]] によって[[キャッシュ可能性]]を[[起源鯖]]側で指定できるようになっています (>>411, >>415, >>418)。 * 歴史 ** 誕生 [REFS[ - [44] [CITE[Request Headers in the HTTP protocol]] ( ([TIME[2001-11-29 11:01:38 +09:00]] 版)) ]REFS] ** RFC [REFS[ - [46] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2012-02-18 23:25:56 +09:00]] 版) - [405] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2012-02-18 23:25:56 +09:00]] 版) - [407] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) - [408] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) - [409] '''[CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) ''' - [415] [CITE@en[RFC 2069 - An Extension to HTTP : Digest Access Authentication]] ([TIME[2012-02-26 10:05:21 +09:00]] 版) - [414] '''[CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-01-09 20:55:20 +09:00]] 版) ''' - [418] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) ]REFS] [FIG[ [FIGCAPTION[ [45] RFC 1945 (HTTP/1.0) 10.2; RFC 2068・2616 (HTTP/1.1) 14.8 Authorization ]FIGCAPTION] > A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--[DEL[[DEL[[INS[{1945}]] may]] [INS[[INS[{2068}]] MAY]] do]] [INS[[INS[{2616}]] does]] so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. サーバーに (普通は、でも必要ではないけど、 401 応答を受け取った後に)、 認証されたいと思う利用者代理者は、 Authorization 要求頭欄を要求に 含めることでそう出来ます。 Authorization 欄の値は 要求されている資源の領域に対しての利用者代理者の認証情報を含んだ 証明書で構成されます。 > - Authorization = "Authorization" ":" credentials > HTTP access authentication is described in [DEL[[INS[{1945・2068}]] section 11]] [INS[[INS[{2616}]] "HTTP Authentication: Basic and Digest Access Authentication" [43]]]. If a request is authenticated and a realm specified, the same credentials [DEL[[INS[{1945}]] should]] [INS[[INS[{2068}]] SHOULD]] be valid for all other requests within this realm [INS[[INS[{2616}]] (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks)]]. HTTP 接続認証は『HTTP 認証: 基本接続認証と要約接続認証』 で説明されています。要求が認証されて領域が指定されていれば、 同じ証明書が当該領域内のすべての他の要求に対して妥当である '''べきです'''。 (認証方式自体はそうでないことを必要としない (例えば挑戦値により変化する証明書や同期時計の使用が無い) と仮定します。) [DEL[ > [INS[{1945}]] Responses to requests containing an Authorization field are not cachable. [CODE(HTTP)[Authorization]] 欄を含んだ要求に対する応答はキャッシュ可能ではありません。 ]DEL] [INS[ [411] > [INS[{2068〜}]] When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: 共有キャッシュが Authorization 欄を含んだ要求を受け取った時、 他のどの要求への返信としても対応する応答を返しては'''いけません'''。 但し次のうちのいずれかの例外を除きます。 > = 1. If the response includes the [DEL[[INS[{2068}]] "proxy-revalidate" Cache-Control]] [INS[[INS[{2616}]] "s-maxage" cache-control]] directive, the cache MAY use that response in replying to a subsequent request[DEL[, but [INS[{2068}]] ]][INS[. But (if the specified maximum age has passed) [INS[{2616}]]]] a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. [INS[[INS[{2616}]] (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy MUST always revalidate it before re-using it.]] = 2. If the response includes the "must-revalidate" [DEL[Cache-Control]] [INS[cache-control]] directive, the cache MAY use that response in replying to a subsequent request[DEL[, but]][INS[. But if the response is stale, ]] all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. = 3. If the response includes the "public" [DEL[Cache-Control]] [INS[cache-control]] directive, it [DEL[may]] [INS[MAY]] be returned in reply to any subsequent request. = 応答が "s-maxage" cache-control 指令を含んでいたら、キャッシュは 後続要求に返信するのにその応答を使っても'''構いません'''。 しかし (指定された最大年令が経過したら) 串キャッシュはまず 源サーバーと再検証し'''なければなりません'''。 そのとき新しい要求からの要求頭を使って源サーバーが新しい要求を 認証出来るようにします。 (これは s-maxage に定義された振舞いです。) 応答が "s-maxage=0" を含んでいる場合、串は再利用する前に常に 再検証し'''なければなりません'''。 = 応答が "must-revalidate" cache-control 指示を含んでいる場合、 キャッシュはその応答を後続要求への返信に使っても'''構いません'''。 しかし要求が腐ったら全てのキャッシュはまず源サーバーで 再検証し'''なければなりません'''。この時新しい要求からの 要求頭を使って源サーバーが新しい要求を認証出来るようにします。 = 要求が "public" cache-control 指示を含んでいる場合、 どの後続要求への返信でも返して'''構いません'''。 ]INS] * License [[RFCのライセンス]] ]FIG] * メモ [419] [CITE[IRC logs: freenode / #whatwg / 20130506]] ( ([TIME[2013-05-16 21:16:27 +09:00]] 版))