3

rfc 1738は、「検索部分」でのスラッシュのエンコードについて正確ではありません。

オクテットに対応する文字がスキームで予約されている場合、オクテットをエンコードする必要があります。

...

英数字、特殊文字「$-_.+!*'()」、および予約された目的で使用される予約文字のみが、URL 内でエンコードされずに使用できます。

...

'path' および 'searchpart' コンポーネント内では、"/"、";"、"?" 予約されています。

URLの検索部分の「/」の「予約された目的」は何ですか?

サーバーがコード化されていないスラッシュを処理する場合、仕様に従ってスラッシュをエンコードする本当の理由はありますか?

スラッシュ付きの英数字だけの URL パラメータを常にデコードする必要があると、気が狂いそうになります。

これが人生の例です：

http://localhost/login?url=/a/path/to/protected/content

対

http://localhost/login?url=%2Fa%2Fpath%2Fto%2Fprotected%2Fcontent "

4

1 に答える 1

2

RFC 3986は RFC 1738 を更新することに注意してください(ただし、廃止されたわけではありません。これは、矛盾するのではなく、明確にすることを目的としていることを示していると思います)。

RFC 3986 のセクション 3.4 ではquery、URI の一部の構文は次のようになっています。

query       = *( pchar / "/" / "?" )

URI の ABNF は、便利なように付録 A に集められています。

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded   = "%" HEXDIG HEXDIG
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

これは、スラッシュがクエリ部分で正当であるため、エンコードする必要がないことを明確に示しています。特に、あなたの例http://localhost/login?url=/a/path/to/protected/contentはそのままで問題ありません。http://localhost/login?abc123-.+~!$&'()*+,;=%00/?:@

セクション 2.4 は、URI の一部に予約文字を含めたい場合にのみ、文字をエンコードする必要があることを示しています (ここでは当てはまりません)。

于 2012-07-02T23:24:17.177 に答える