問題タブ [http-protocols]

質問する

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

50 問題
Newest
Active
Bountied
318
Unanswered
0 投票する
1 に答える
5024 参照

c# - c# で tcp 接続を介してポスト リクエストを作成する

私は主に学ぶためにこの質問をしています。最初に、通常の投稿リクエストを作成しようとしましたが、次のエラーが発生しました: C#: Handling WebClient "protocol violation"。それから私は何が起こっているのかを理解するために生のつながりを作ろうとし、最終的に好奇心旺盛になりました.

とにかくここに私の質問があります：

フィドラーを使用して、複製しようとしている投稿要求をキャプチャしています。フィドラーでキャプチャしたときのリクエストは次のようになります。

ここに画像の説明を入力

上にリクエストがあり、下にレスポンスがあることに注意してください。また、私の応答が 200 OK であることも確認してください

これが機能していることのもう 1 つの証拠は、次のcurl コマンドを実行したときです ここに画像の説明を入力 。

今、私はc#で同じことをしたいと思っています。ここに私のコードがあります:

なぜ 200 応答が得られないのですか? 何が間違っているのでしょうか :/ . 私は自分が間違っていることを学びたいと思います。

0 投票する
0 に答える
608 参照

java - HTTP接続を適切に管理するには?

クライアントに送信しているファイルに、将来の HTTP 要求を表す他のリンクされたファイルが含まれていることを考慮して、次の HTTP 応答を適切に管理する方法を考えています。

本文が終了したことをクライアントに示す PrintWriter を閉じることができることはわかっていますが、それを行うと、「first.html」内のリンクされたページに対する後続の要求を受け取る方法がわかりません。content-length ヘッダーを含めようとしましたが、「first.html」ブロック/ストールを送信した後に入力ストリームから読み取ろうとすると、長さを誤って計算した可能性があります。これは、first.html ファイルの送信が完了したことをクライアントが認識していないことを示しています。私はRFC 2616を読みましたが、率直に言って、適切な例がないと理解できません。プロトコルに関しては、私は本当の子供なので、助けていただければ幸いです。

0 投票する
1 に答える
1805 参照

database - 論理的な削除と論理的に削除されたリソースの回復のための REST は制限されています

これはあまり技術的な質問ではなく、主題についての考察です。

REST は、HTTP プロトコルを使用してリソースを提供する優れた方法を民主化し、開発者がリソースとユーザー インターフェイスを分割することで最もクリーンなプロジェクトを実行できるようにしました (バックエンドは現在、REST API を使用するバックエンドのみを実際に扱っています)。

これらの API については、ほとんどの場合、GET、PUT/PATCH (うーん?)、POST、および DELETE を使用しますが、どちらも CRUD データベースを模倣しています。

しかし、プロジェクトに費やす時間が経つにつれて、多くの優れた機能を追加することで UX を改善できると感じています。たとえば、ユーザーがリソースを削除することを恐れる理由は何でしょうか? 回復システムを設置しないのはなぜですか (Google Keep アプリで見られるように、削除を元に戻すことができます。これは、UX の点で素晴​​らしいと思います)。

意図しない削除を防ぐ方法の 1 つは、リソースを表すテーブル内の列を使用することです。たとえば、本を削除しようとしているので、削除ボタンをクリックすると、データベースでこの行に「deleted = TRUE」というフラグのみが付けられ、リソースのリストを参照するときに削除された行が表示されなくなります (GET)。 .

これは、DELETE と DESTROY の "メソッド" の間に区別がないため、私たちの大切な REST パターンと競合します。

私が言いたいのは、REST を私たちの UX ニーズに合わせて進化させること、つまり HTTP プロトコルも進化させることを考えるべきか、それとも純粋なリソース管理としてとどまり、代わりに HTTP プロトコルを気にせず従うべきかということです。回避策を使用してそれに適応するだけです（ソフト削除にPATCHを使用するなど）？

個人的には、リソースを可能な限り適切に認定しようとしているため、少なくとも 4 つの新しいプロトコルを確認したいと考えています。

  • DELETEは、他のメソッドが影響を与えるのを防ぐ方法になります
  • このリソースの痕跡を完全に削除することで、 DESTROYはより劇的になります。
  • RECOVERは、他のメソッドに対して「こんにちは、彼は戻ってきます。お楽しみに」と言う方法です。
  • TRASHは GET に似ていますが、DELETED リソースのみを対象としています

それについて考えさせられたのは、このリソースの動作に対処するためのクリーンな REST ソリューションの研究です。私はいくつかのウェブサイトの投稿を見てきました

PUT または PATCH を使用してソフト削除を使用可能にするようにというアドバイスですが、それは正しくないように思えますね。

この問題についての私の考え:

  • 新しい HTTP メソッドの提案と以前のメソッドの更新との間に大きなステップはありますか (HTTP/2 が話題になっていると聞きました。
  • Web 開発領域の外では意味がありますか? この変更は、私たちの他のドメインに影響を与える可能性がありますか?

12345678910