21

http または https の絶対 URL を想定します。URL のパスの前にある部分の「公式」または一般的に受け入れられている名前を探しています。

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \_____________________________/
                  |
              this part

RFC 3986では、URL 構文部分を次のように定義しています。

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \__/   \______________________/\_________/ \_________/ \__/
      |               |                |            |        |
   scheme         authority           path        query   fragment

RFC 6454では、URL のオリジン (「同じオリジン」) をトリプル (スキーム、ホスト、ポート) として定義しています。

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \__/           \______________/
      \________________/
              |
           origin

したがって、どちらの用語も適切ではありません。私が見ている部分に適切な用語はありますか、それとも「スキーム（プラス://）プラス権限」で立ち往生していますか？

4

2 に答える 2

9

パスの前に来る URL の部分の実際の名前と現在の URL 標準による名前は、実際にはoriginです。

URLの://一部は、(もちろん低レベルのパーサーを除いて) URL を消費または処理するものの実際の動作についての議論で言及する必要のない単なる構文 (または字句?) の成果物です。

ユーザー名とパスワードの部分は、不適合な誤機能であり、現在は歴史的なエラーとして議論するのにのみ役立ちます. 現在の URL 標準の関連部分には、これについての記述があります。

URL 文字列内で URL レコードのユーザー名またはパスワードを表現する準拠する方法はありません。

したがって、実際には、現在の標準が URL を定義する方法に沿った URL の通常の議論では、最も高いレベルの部分がただ 4 つの部分であるという観点から URL について説明するだけで十分です: origin、path、query (一部）、およびそのフラグメント（一部）。

確かに、それは少なくとも現在の URL 標準自体がそれを制限しているものです。

于 2015-09-18T18:08:19.037 に答える
1

それはまさに「策略＋権威」でなければならない。スキーマと権限だけを持つ有効な URI はあり得ないことに注意してください。そのため、この組み合わせは議論の単位としてはあまり出てきません。そのため、名前にはなりませんでした。

HTTP URI では userinfo が許可されていないことにも注意してください。特定のスキームは、特定の部分の値を禁止または制限することができます。一部のブラウザーには、userinfo ヘッダーと基本認証ヘッダーを受け入れるという設計上の欠陥がありましたが、ほとんどのブラウザーは、許可したとしても、少なくともこれが行われていることについて警告します。

于 2015-09-21T15:26:03.677 に答える