要約

  • 207 の結果が整列していても、サーバーが任意に選んだ適合部分集合かもしれない。507 の切り詰め通知を失えば、部分結果が完全なランキングに見えてしまう。
  • 行がない理由は FALSE だけではない。UNKNOWN、権限、スコープ、未評価、リダイレクト、索引状態を含むため、不在を資源の不存在へ直結できない。

並びが正しいことと、選び方が完全なこと

検索画面の一番上にあるものは、全体でも一番上だと思われやすい。RFC 5323 は、その推論が成立しない応答を正規に定義している。サーバーは計算や転送の負担を抑えるため、結果集合を切り詰められる。

このとき HTTP は 207 Multi-Status のままで、検索 arbiter に対する 507 を応答内に置き、部分結果を含めることが推奨される。未調査のまま残った適合資源が多数あるかもしれず、返される部分は適合集合の任意の部分集合でよい。

DAV:orderby が指定されていれば、返された部分はその順に並べなければならない。しかし、任意の部分を並べたものは全体の上位群ではない。中継層が 507 だけを捨てると、正しい並びが誤った完全性を補強する。

DAV:limit は返却数や処理量の上限をクライアントから要求するが、サーバーは無視できる。順序と上限が同時にあれば高順位を返すことが望ましい。それでも、要求値、実際の計算予算、切り詰め通知は別々に保存すべきだ。

問いを受けた場所と、探した場所

SEARCH メソッドは問い合わせと結果を運ぶ。意味は選択した query grammar が決める。Request-URI は検索を実行する arbiter を示すが、それ自体が検索対象の scope とは限らない。

DAV:basicsearch では DAV:from が scope を定義する。href と depth の組で、0 は集合自身、1 は直接の子、infinity は子孫全体を含む。相対 URI は Request-URI を基準に解決され、絶対 URI はサーバーの対応範囲と方針の下で別の場所を示せる。

複数 scope の対応は任意である。未対応なら要求を失敗させる必要があり、一部だけを黙って処理してはならない。リダイレクト参照も当然には追跡されない。infinity という語だけで、論理名前空間の全枝を走査したとは言えない。

監査証跡が where 句だけを保持し、解決済み scope と arbiter を失えば、同じ問いを再現できない。Request-URI を scope として記録すれば、再実行時に別の母集団を探すことになる。

UNKNOWN は「違う」ではなく「決められない」

条件式は TRUE、FALSE、UNKNOWN の三値で評価され、TRUE の資源だけが結果に入る。非表示行を FALSE とみなす二値の台帳は、プロトコルより強い結論を作る。

PROPFIND なら非 2xx となる属性は NULL として扱う。NULL は空文字列ではない。空文字列は定義済みの値であり、NULL はその文脈で値が得られない状態だ。読み取り権限のない属性は存在しないかのように、読めない内容は GET が 4xx を返すかのように評価される。

これは情報漏えいを防ぐ。SEARCH は GET や PROPFIND で見えない情報を明かしてはならない。そのため、同じ XML と scope でも principal が違えば結果が違い得る。どちらかが壊れているとは限らない。

欠落は FALSE、UNKNOWN、権限不足、scope 外、切り詰め前に未評価、未追跡の参照、索引遅延、更新後の変化を含む。不存在はその一候補にすぎない。

発見応答は実行受領書ではない

DASL ヘッダーと DAV:supported-query-grammar-set は、資源が理解する grammar を知らせる。しかし grammar 名だけでは、有効な問い合わせを構成する情報が足りない。

Query Schema Discovery は、検索、選択、整列に使える属性と任意演算子を示せる。QSD 自体は任意で、schema は arbiter と scope に依存する。principal によっても変わり得るが、その全要因がプロトコル上見えるわけではない。

searchable は、サーバーが属性を検査する意思を示すだけで、全資源に属性が定義されている保証ではない。grammar URI も識別子であり、HTTP の形をしているからといって取得してはならない。

score の比較も局所的だ。同じ検索システムが同じ集合に対して実行した場合を除き、別結果の数値を比べる意味は一般にない。ランキング番号はエンジン、コーパス、索引時点から独立した評価ではない。

href の一行と資源の一個

scope 内の複数 URI が同じ資源へ対応する場合、サーバーは一つだけを返すことが望ましい。DAV:resource-id は重複候補を見つける助けになるが、返された href を永久の唯一名にはしない。

行数をそのまま物体数に変換できず、見えない alias を失われた別資源とも数えられない。href、resource-id、propstat、arbiter、時刻を保ち、同一性判断は後段の推論として記録する。

成功応答はキャッシュしないことが推奨される。集合、権限、属性、索引は変化する。SEARCH は時点観測であり、固定スナップショットではない。

本番で残す検索台帳

元の XML、grammar、Request-URI、解決済み scope、depth、リダイレクトと版の指定、認証 principal、権限文脈、select、条件木、orderby、limit を保存する。応答では 207、全 response と propstat、href、resource-id、score、507、取得可能なら索引 epoch を保存する。

別の列挙証拠なしに「全件」と表示しない。UNKNOWN、権限、scope、切り詰めが残る間は、欠落を FALSE にしない。異なるエンジンや集合の score を比較せず、grammar discovery を検索成功として数えない。

固定上限、消えた 507、schema の変化、許可済み PROPFIND 列挙との差、同じ ID の複数 href、外部 XML entity を監視する。高コスト問い合わせは DoS の入口でもあるため、予算とパーサー防御が必要だ。

RFC 5323 が与えたのは、データの近くで問いを処理する方法である。検索索引を記録体系へ昇格させたわけではない。整った百行は有用だが、その外側に何があるかは別に証明しなければならない。

参照資料