0

URL に <*> のような特殊文字を含むいくつかのパラメーターを Web サーバー ウィッチに送信する必要があります。

元：http://localhost/mypage/X123*12362issasa.

この特殊文字は、正規表現に使用します。

これを試すと、これが得られます

「403 Forbidden このサーバーの /mypage/X123*12362issasa. にアクセスする権限がありません。」

apache_error.log には次の行が含まれています。

[エラー] [クライアント 127.0.0.1] (20025) 指定されたパスにワイルドカード文字が含まれていました: /mypage/X123*12362issasa へのアクセスに失敗しました

私の .htaccess には次の行が含まれています。

Options +ExecCGI

AddHandler cgi-script .cgi .pl .py .php

DirectoryIndex mypage.pl

<IfModule mod_charset.c> 
  CharsetRecodeMultipartForms off 
</IfModule>

<IfModule mod_rewrite.c>
    RewriteEngine on 
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ mypage.pl?oid=$1
</IfModule>

この種の特殊文字を受け入れるために、.htaccessファイルを適切に構成するのを手伝ってもらえますか? どんな助けも高く評価されます。ありがとう。

4

1 に答える 1

3

URL にアスタリスクを使用してはならない理由。

1 )標準に従ってエンコードされていない URL でアスタリスクを使用できますが、 RFC 1738 URL (Uniform Resource Locators)によれば、これは特殊文字です。したがって、この場合は特別な用途があります。

RFC 1738 ユニフォーム リソース ロケーター (URL) 1994 年 12 月

予約済み：

多くの URL スキームは、特定の文字を特別な意味のために予約しています。URL のスキーム固有の部分に現れる文字には、指定されたセマンティクスがあります。オクテットに対応する文字がスキームで予約されている場合、オクテットをエンコードする必要があります。文字「;」、「/」、「?」、「:」、「@」、「=」、および「&」は、スキーム内で特別な意味のために予約されている文字です。スキーム内で他の文字を予約することはできません。

通常、URL は、オクテットが文字で表されている場合とエンコードされている場合とで同じ解釈をします。ただし、これは予約文字には当てはまりません。特定のスキーム用に予約された文字をエンコードすると、URL のセマンティクスが変わる場合があります。

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

一方、エンコードする必要のない文字 (英数字を含む) は、予約された目的で使用されていない限り、URL のスキーム固有の部分内でエンコードできます。

さらにヘッダーでは、 RFC 2068 HTTP 1.1に従ってサーバーのみの宣言に使用されます。

9.2 オプション

OPTIONS メソッドは、Request-URI によって識別される要求/応答チェーンで使用可能な通信オプションに関する情報の要求を表します。このメソッドにより、クライアントは、リソースのアクションを示唆したり、リソースの取得を開始したりすることなく、リソースに関連付けられたオプションや要件、またはサーバーの機能を判断できます。

サーバーの応答がエラーでない限り、通信オプションとして考えられるもの以外のエンティティ情報を応答に含めてはなりません (たとえば、Allow は適切ですが、Content-Type は適切ではありません)。このメソッドへの応答はキャッシュできません。

Request-URI がアスタリスク (「*」) の場合、OPTIONS 要求はサーバー全体に適用されることを意図しています。200 応答には、適用可能な一般または応答ヘッダー フィールドに加えて、この仕様で定義されていない拡張機能を含む、サーバー (たとえば、Public) によって実装されたオプション機能を示すヘッダー フィールドを含める必要があります。セクション 5.1.2 で説明されているように、「OPTIONS *」リクエストは、パス情報なしで Request-URI に宛先サーバーを指定することにより、プロキシ経由で適用できます。

Request-URI がアスタリスクでない場合、OPTIONS 要求は、そのリソースと通信するときに使用できるオプションにのみ適用されます。200 応答には、適用可能な一般または応答ヘッダー フィールドに加えて、この仕様で定義されていない拡張機能を含む、サーバーによって実装され、そのリソースに適用可能なオプション機能 (たとえば、Allow) を示すヘッダー フィールドを含める必要があります。OPTIONS リクエストがプロキシを通過する場合、プロキシはレスポンスを編集して、プロキシの機能に適用され、そのプロキシを介して利用できないことがわかっているオプションを除外する必要があります。

2) RFC 3986 URI Generic Syntax 2005 年 1 月時点で予約文字 (サブ区切り文字) です(これを指摘してくれた @Daxim に感謝します)。

2.2. 予約文字


URI には、「予約済み」セットの文字で区切られたコンポーネントとサブコンポーネントが含まれます。これらの文字は 、一般的な構文、各スキーム固有の構文、または URI の逆参照アルゴリズムの実装固有の構文によって
区切り文字として定義される (または定義されない) ため、「予約済み」と呼ばれます。 URI コンポーネントのデータが 区切り文字としての予約文字の目的と競合する場合、URI を形成する前に、競合するデータをパーセントでエンコードする必要があります。



予約済み = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

サブデリム = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

予約文字の目的は、URI 内の他のデータと区別できる一連の区切り文字を提供することです。対応するパーセントでエンコードされたオクテットでの予約文字の置換が異なる URI は同等ではありません。予約文字をパーセントでエンコードするか、予約文字に対応するパーセントでエンコードされたオクテットをデコードすると、ほとんどのアプリケーションで URI が解釈される方法が変わります。したがって、予約済みセットの文字は正規化から保護されているため、URI 内のデータ サブコンポーネントを区切るためにスキーム固有およびプロデューサー固有のアルゴリズムで安全に使用できます。

3 ) 一部のホスト オペレーティング システムでは、ワイルドカードとして使用されます。

いずれにしても、リクエスト URI でエンコードされていないアスタリスクを使用することは避けてください。

于 2013-07-30T14:05:04.830 に答える