2012-03-22 1 views
2

私は、メディアボックス上のamazon cloudfront cdnとsignedd URLを介してビデオストリーミングのコンテキストで長いURLに問題があります。HTTPリクエストのコンテキストで255バイトの文字列はどのくらいの期間ですか?

RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1状態:

Note: Servers should be cautious about depending on URI lengths 
above 255 bytes, because some older client or proxy implementations 
may not properly support these lengths. 

これは私がに実行しています正確に限定するようです。 255文字の長いURLは機能するため、256文字は使用できません。

しかし、ASCIIで文字が7ビットでエンコードされていると思ったので少し混乱します。

また、URL内の有効な文字はすべてASCIIのアルファベットで覆われていることがわかります。

エラー検出/修正のために、より多くの文字をサポートするために8ビットアルファベットに拡張するか、1バイトに欠けている1ビットを使用するのが一般的な方法であることはわかっています。

私の質問は今すぐです:

httpリクエストの文脈では。 255バイトの長さの場合、正確に何を意味しますか。この数字は何文字ですか?

+0

HTTP 1.1については、[RFC 2161](http://tools.ietf.org/html/rfc2616)に頼るべきです(ただし、この場合は同じことです)。 – Bruno

+0

またはさらにhttpbis;) – Evert

答えて

1

ASCIIのみは、各バイトの最初の7ビットがですが、すべての文字が1バイトを占めます。

+0

+1 ...何とか私は何とか考えました...どこでそれに賛成できますか?あなたはその理由を想像できますか? ...それはデータを無駄にしないのですか? –

+0

最大の理由は、世界がちょうど8ビットバイトで動作することです。私は、おそらく7ビットレジスタを持つCPUがどこにあったのかからASCII文字列を得たはずです。本当にあなたの研究をすることはできませんが、あなたはあなたの答えを持っています:) – Evert

+0

"どこでそれを払うことができますか?" パピルススクロールを見つける必要があるかもしれません。 –

1

HTTP(プロトコル)に255文字の制限はありません。しかし、特定のソフトウェアコンポーネントには限界があるかもしれません。

またそのRFC 2068は本当に古代であることに注意し、この上の最新かつ最高のは、ここで見つけることができます:http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-19.html#rfc.section.3.1.1.p.10

リクエストラインの長さの「さまざまなアドホックな制限が実際に発見されたことがことが推奨されます。すべてのHTTP送信者と受信者は、少なくとも8000オクテットの要求ライン長をサポートします。

2

255バイトは255文字になります。このメモは経験則です。プロキシを経由しない限り、ほとんどのURIはリクエストヘッダに分割されます(ホストは一般的にリクエストラインではなくHostヘッダにあります)。

この255バイトの制限は、現在のソフトウェアでは現在のところ廃止されていると思いますが、まだ制限があります。 Internet Explorer has a 2083-character limit on URLs。私はFirefoxがより多くのことを処理できると思うが、とにかくあなたのサイトがIEで動作するようにしたいのであれば、ほとんど問題はない。

URLのシグネチャは厄介です。証明書がなく、署名者の名前がない場合の回避策があります。この場合、受信者は、署名がどこから来たのか、それを確認するための公開鍵を知ることが期待されます。これは多かれ少なかれSAML HTTP Redirect binding does (around line 594)です。あなたがそのようなトリックを使用することができない場合は、単にPOSTを使用する必要があります。

関連する問題