問題タブ [rfc3986]

RFC 3986 は、URI のホスト コンポーネントが「大文字と小文字を区別しない」ことを指定しています。ただし、UCS または UTF-8 文字に関して「大文字と小文字を区別しない」が何を意味するかは指定されていません。

RFC に示されている例 (例: " <HTTP://www.EXAMPLE.com/> is equal to <http://www.example.com/>") から、「大文字と小文字を区別しない」ということは、少なくとも文字 A ～ Z が UTF-8 文字セットの文字 32 の前にある文字と同等であると見なされることを意味すると推測できます。つまり、 AZ。ただし、この範囲外の文字をどのように扱うべきかについては言及されていません。したがって、www.OLÉ.comというエンコードも正規化もされていない登録名が与えられた場合、RFC で許容される正規化の 3 つの形式が考えられます。

1. 小文字でwww.olé.comに変換し、パーセント エンコードして www.ol%E9.com に変換します
2. www.olÉ.comには A ～ Z 文字のみを小文字にしてから、www.ol%C9.com にパーセント エンコードします。
3. パーセントで www.OL%C9.com にエンコードしてから、パーセントでエンコードされていない部分を小文字で www.ol%C9.com にすると、2 と同じ結果になります。

質問は次のとおりです。どちらが正しいですか。ケース 1 の場合、どの文字が大文字と見なされ、どの文字が小文字と見なされるか (また、どの文字に大文字と小文字がないか) を定義するものは何ですか?

明らかに％をエンコードする必要があります。標準に関するウィキペディアの記事には次のように書かれています。

パーセント（ "％"）文字は、パーセントエンコードされたオクテットのインジケーターとして機能するため、そのオクテットをURI内のデータとして使用するには、「％25」としてパーセントエンコードする必要があります。

予約文字としても記載されていないのはなぜですか？明らかに、URIのコンテキストで特別な何かを示すために予約されています...

私の単体テストではUriComponentsBuilder#URI_PATTERN、Spring MVC 3.1.1 の正規表現と一致しない無効な URI の例を見つけたいと思います。

UriComponentsBuilder.fromUriString()で失敗する単一の文字列を見つけるのに苦労していますIllegalArgumentException。私が試したものはすべて、正規表現チェックを有効な URI として渡します。

のようなメールアドレスを含む URL を扱うサーバーをセットアップすることを検討します。

RFC 3986 によると、@ は機関部分 = //mydomain.com/ で予約されていますが、パス部分 /....... では予約されていないため、現在、パスで電子メール アドレスを使用しても問題ないと思います。

そうは言っても、 本番環境でhttp://mydomain.com/me@mail.comのように使用しても安全かどうかはまだわかりません。

お知らせ下さい。ありがとう。

RFC3986 では、個々の URI スキームの特定の構文を定義した RFC1738 の部分が除外されており、これらの部分は別のドキュメントとして更新されると記載されていますが、見つかりません。更新中の個別のドキュメントがどこにあるのか、誰でも教えてくれます。HTTP URL スキームの parsestrong テキストを書きたいので、それを参照する必要があります。

RFC 3986 セクション 3 - 構文コンポーネントによると:

パスは空 (文字なし) の場合がありますが、スキームとパスのコンポーネントは必須です。

空にすることができる場合、パスコンポーネントがどのように必要になるかを誰かが明確にすることができますか? このコンテキストでの「必須」の定義を誤解しているのかもしれませんが、「空であってはならない」という意味であると想定しました。これは、ここでの仕様と明らかに矛盾しています。

URL について質問があります。

RFC 3986を読みましたが、まだ 1 つの URL について質問があります。

URI に機関コンポーネントが含まれている場合、パス コンポーネント
は空にするか、スラッシュ ("/") 文字で開始する必要があります。URI に機関コンポーネントが含まれていない場合、パス
を 2 つのスラッシュ文字 (「//」) で始めることはできません。さらに、URI 参照
(セクション 4.1) は相対パス参照である場合があり、その場合、
最初のパス セグメントにコロン (":") 文字を含めることはできません。ABNF
では、これらのケースを明確にするために 5 つの個別のルールが必要です。そのうちの 1 つだけが、特定の URI 参照内のパス部分文字列と一致します。「パス コンポーネント」という一般的な用語を使用
して、パーサーによってこれらのルールのいずれかに一致する URI 部分文字列を説明します。

それ//server.com:80/path/infoは有効です (スキーマの相対 URL です)。

それが有効であることも知ってhttp://server.com:80/path//infoいます。

しかし、次のものが有効かどうかはわかりません。

私の質問の背後にある問題は、に制限http://server.com:80//path/infoされた URI によって作成された場合、Cookie が に送信されないことです。http://server.com:80/path/info/path

私はこの質問を読みました: URL に括弧を入れても大丈夫ですか? および関連するRFC 3986。

この質問への回答では、[およびは RFC によってgen-delims]として分類されているため、エンコードする必要があると述べていますが、そうしないとどのように問題が生じるかについては説明していません。

そのため、次のような URL の何が問題なのか理解できません。

&たとえば、クエリ パラメータ間のセパレータとして使用されるため、エンコードする必要がある理由は明らかです。

しかし、URLエンコードされていない場合に意図を混乱させるURLでのandの使用は何ですか?[]