問題タブ [rfc]

HTTP 1.1 サーバーの実装を確認しました。これは、クライアント側で発信チャネルのシャットダウンを検出するとすぐに (または、適切な http 応答を送信する前または後に) クライアント接続を終了します。これは HTTP 1.1 実装に準拠していますか?

RFC 2616 セクション 8.1.4 は、これが適切な動作であることを示唆しているようです。

クライアントまたはサーバーがタイムアウトしたい場合、トランスポート接続で適切なクローズを発行する必要があります。クライアントとサーバーは、トランスポートの反対側が閉じるのを常に監視し、適切に応答する必要があります。

...

ネットワークまたはクライアントの障害が疑われる場合を除き、サーバーは応答の送信中に接続を閉じるべきではありません。

私はそれを正しく解釈していますか？HTTP 1.1 のコンテキストでのハーフクローズド接続処理に関するより明示的な参照はありますか?

問題領域

特定のパス セグメントがRFC2396に対して有効かどうかを定義する必要があります。仕様は次のように述べています。

たとえば、/fooは有効なパス セグメントですが、/fo?oエスケープされていないためではありません?。上記の例を修正するには、パス セグメントを次のように記述し/fo%3Foます。

ただし、仕様では、サーバーに到着する URI (URL バーに入力されたと考えてください) の有効性のみを定義しています。

実際に検証する必要があるのは、エスケープされていないパス セグメントが有効かどうかです。上記の例を続けると、エスケープを解除したときに得られるものと/fo?o同様に、有効なリソースになります。?%3F

これはまた、URLhttp://foo.com/first/sec%2fondが 2 つのエスケープされていないパス セグメント/firstおよびに解決されることを意味し、後者は 2 つの別々のセグメントではなく1 つ/sec/ondのセグメントとして扱われる必要があるだけでなく、構文的にも有効です (エスケープされていないパス セグメントとして)。

質問

• 仕様を正しく理解していますか?
• エスケープされていないパスセグメントのJavaバリデーターを提案できる人はいますか?
• 誰かが自明ではない失敗例を提案できますか?
• U+00FF より上の文字はパス セグメントで使用できませんか? 少なくともドメイン名ではサポートされていると思いました。

編集: マイクが正しく指摘したように、RFC3986 は RFC2396 を廃止しました。とにかく、新しい RFC は古いものよりも多くのケースを処理する (そして、一部のパス セグメントを不当にしない) と信じているため、同じ質問が適用されます。

私はFFMPEGストリーミングベースラインh264ビデオを持っています。これをRTPにカプセル化し、デコードのためにSIP電話に送信する必要があります。デコードの進行には、Windows用のh264プラグインとMirialでLinphoneを使用しています。ただし、FFMPEGから巨大なフレームサイズ（3Kb〜9Kb）を取得することがありますが、これは明らかにMTUに適合しません。

これらのフレームを「現状のまま」送信し​​、IPフラグメンテーション機能を信頼すると、一部の電話はそれを十分に再生できますが、他の電話はチョークしてストリームをデコードできません。これは、ストリームがRFC 3984に準拠していないためだと思います。これは、MTUに収まらないパケットを異なるNALUに分離し、RTPのマーク機能でフレームの終わりをマークする必要があることを指定しています。

IまたはPフレームをどこで「カット」できるかをどのように知ることができますか？断片化されたh264パケット（マークラベルのないもの）が0xF8で終了することがありますが、パターンを完全に取得できず、RTPを介してこれらのパケットを送信する方法を説明するRFC 3984で、その方法が指定されていないことに気付きました。

更新：最大サイズのNALUを生成する方法をX264ライブラリに指示する方法を知っている人はいますか？そうすれば、この問題を回避できるはずです。みんな、ありがとう

root@[127.1]構文的に有効な電子メールアドレスですか？

なんで？なぜだめですか？

次のような URL のすべてのパラメーターを取得するアプリケーションがあります/category/subcategory/sub-subcategory。のように、URL の末尾に追加のパラメーターを指定できるようにしたいと考えていますpage-2/order-desc。これにより、URL 全体がcat/subcat/sub-subcat{delimiting-character}page-2/order-desc.

私の質問は、どの文字を として使用できるか{delimiting-character}です。私は「:」を好む傾向があります。これは、他の場所には決して表示されないことは確かですが、それが標準に準拠するかどうか、または少なくとも将来的に問題が発生しないかどうかはわかりません.

私が覚えているように、vimeo は次のようなものを使用していました:vimeo.com/video:{code}しかし、彼らはこれを変更したようです。

私は FTP サーバーを開発していますが、STOR が発生する前にファイル サイズが必要です。ALLO というコマンドがあることを確認しました。クライアントにそのコマンドを強制的に発行させる方法があるかどうか疑問に思っていました。もちろん、クライアントは事前にファイル サイズを把握しています。

乾杯。

RTSP制御チャネルにUDP を使用する RTSP 対応プレーヤーはまだ見たことがありませんが、RFC2326 では UDP の使用が許可されています。ただし、RTSP 応答の送信先をクライアントがサーバーに通知する方法は指定されていません。これについて確立された規則はありますか、それとも私が作成する必要がありますか?

RFC 2060 の APPEND コマンドの例の最後のパラメータが何かを理解するのを手伝ってくれませんか。例 C: A003 APPEND saved-messages (\Seen) {310} と {310} の意味を教えてください。

ありがとうございます。

hrefURIを生成する必要があります。パーセントエンコーディングが必要な予約文字を除いて、すべて簡単です。たとえば、へのリンクは次の/some/path;elementように表示されます（単一のエンティティを表す<a href="/some/path%3Belement">ことはわかっています）。path;element

最初はこれを行う Java ライブラリを探していましたが、自分で何かを書くことになりました (この質問は Java 固有ではないため、Java で失敗したものについては以下を参照してください)。

したがって、RFC 3986は、いつエンコードしないかを提案しています。私が読んだように、これは、キャラクターがunreserved (ALPHA / DIGIT / "-" / "." / "_" / "~")クラスに分類されるときに発生するはずです。ここまでは順調ですね。しかし、逆の場合はどうでしょうか。%RFC では、パーセント ( ) は常にエンコードが必要であるとのみ言及されています。しかし、他の人はどうですか？

質問:予約されていないものはすべて、パーセントでエンコードできる/すべきであると仮定するのは正しいですか? たとえば、左大括弧(は必ずしもエンコードする必要はありませんが、セミコロンは必要です;。/firstエンコードしないと、次のときに *を探すことになります<a href="/first;second">。しかし、次のよう<a href="/first(second">にすると、予想どおり、常に を探してしまい/first(secondます。私を混乱させているのは、RFC に関する限り、 と の両方が同じクラス(に;あるということです。sub-delims私が想像するように、予約されていないものすべてをエンコードすることは安全な賭けですが、ローカライズされた URI に関しては、SEO 性、ユーザー フレンドリ性についてはどうでしょうか?

さて、Java ライブラリで何が失敗したか。私はそれをやってみまし
new java.net.URI("http", "site", "/pa;th", null).toASCIISTring()
たが、これhttp://site/pa;thは良くありません。同様の結果が観察されました:

• javax.ws.rs.core.UriBuilder
• Spring の UriUtils - 私は両方を試しましencodePath(String, String)たencodePathSegment(String, String)

[*]をクリックしたときにサーバー側/firstで呼び出した結果ですHttpServletRequest.getServletPath()<a href="/first;second">

編集:おそらく、この動作は Tomcat で観察されたことに言及する必要があります。また、Tomcat 6 と 7 の両方が同じように動作することを確認しました。

502 Bad Gateway小さなプロキシを作成しましたが、プロキシサーバー自体に内部エラーがある場合にエラーを返すのが正しいかどうか疑問に思っています。RFCは、これは相手側のサーバーが悪い応答をした場合にのみ行うことであると言っているようです。

サーバーは、ゲートウェイまたはプロキシとして機能しているときに、要求を実行しようとしてアクセスしたアップストリームサーバーから無効な応答を受信しました。

これは、たとえばアップストリームサーバーがcontent-length応答本文の長さとは異なるヘッダーを設定している502場合、つまり応答が無効な場合にエラーを設定する必要があることを意味します。

RFCを誤解していますか？