タグ付けされた質問 「http」

ハイパーテキスト転送プロトコル(HTTP)は、World Wide Web上のコンテンツの転送に使用されるアプリケーションレベルのネットワークプロトコルです。

3
クロスドメインフォームのPOST
私はこのトピックに関する記事や投稿(SOを含む)をすべて見てきましたが、主流のコメントは、同一生成元ポリシーがドメイン間でフォームPOSTを防止するというものです。同じ起源のポリシーがフォームの投稿に適用されないことを誰かが示唆しているのを見た唯一の場所はここです。 もっと「公式」または正式な情報源からの回答を希望します。たとえば、同一生成元がフォームPOSTにどのように影響するか、または影響しないかを扱うRFCを誰かが知っていますか? 説明:GETまたはPOSTを構築して任意のドメインに送信できるかどうかは尋ねていません。私は尋ねています: Chrome、IE、またはFirefoxでドメイン「Y」のコンテンツがドメイン「X」にPOSTを送信できる場合 POSTを受信するサーバーが実際にフォームの値をまったく表示する場合。私がこれを言ったのは、オンラインディスカッションの大多数がテスターがサーバーが投稿を受け取ったと記録しているが、フォームの値はすべて空である/取り除かれているためです。 公式ドキュメント(RFCなど)は、(ブラウザが現在実装しているものに関係なく)予想される動作を説明しています。 ちなみに、同一生成元がフォームのPOSTに影響を与えない場合は、偽造防止トークンが必要な理由がいくらか明らかになります。攻撃者が単純にHTTP GETを発行して偽造防止トークンを含むフォームを取得し、同じトークンを含む不正なPOSTを作成する可能性があると信じるのは簡単すぎるため、「やや」と言います。コメント?


3
HTTP Content-TypeヘッダーとJSON
私はいつも、未知のものを恐れるために、HTTPプロトコルのプロパティのほとんどを使用しないようにしています。 しかし、今日は恐怖に直面し、意図的にヘッダーを使用し始めると自分に言い聞かせました。私はjsonブラウザにデータを送信してすぐにそれを使用しようとしています。たとえば、準備状態4に次のようなAjaxハンドラー関数があるとします。 function ajaxHandler(response){ alert(response.text); } そして、PHPコードにcontent-typeヘッダーを設定しました。 header('Content-Type: application/json'); echo json_encode(array('text' => 'omrele')); ブラウザーに着信データがあることが明確に通知されているのに、ハンドラー関数からプロパティに直接アクセスできないのはなぜapplication/jsonですか?
144 javascript  php  json  http 

3
悪意のあるコードがCORSを悪用するために「Origin」ヘッダーを偽装するのを防ぐにはどうすればよいですか?
私が理解している方法では、foo.comのページで実行されているクライアント側のスクリプトがbar.comのデータをリクエストする場合、リクエストでヘッダーを指定し、Origin: http://foo.comバーがで応答する必要がありますAccess-Control-Allow-Origin: http://foo.com。 サイトroh.comからの悪意のあるコードがヘッダーOrigin: http://foo.comを偽装してバーからページを要求するのを防ぐ方法は何ですか?
142 javascript  ajax  http  cors 

5
サーバー側のCookieを削除する正しい方法
私の認証プロセスでは、ユーザーがログインしたときに一意のトークンを作成し、認証に使用されるCookieに入れます。 したがって、サーバーから次のようなものを送信します。 Set-Cookie: token=$2a$12$T94df7ArHkpkX7RGYndcq.fKU.oRlkVLOkCBNrMilaSWnTcWtCfJC; path=/; これはすべてのブラウザで動作します。次に、Cookieを削除するために、expires1970年1月1日に設定されたフィールドを持つ同様のCookieを送信します。 Set-Cookie: token=$2a$12$T94df7ArHkpkX7RGYndcq.fKU.oRlkVLOkCBNrMilaSWnTcWtCfJC; path=/; expires=Thu, Jan 01 1970 00:00:00 UTC; また、Firefoxでは正常に機能しますが、IEまたはSafariではCookieは削除されません。 では、Cookieを削除する最良の方法は何ですか(できればJavaScriptなしで)?set-the-expires-in-the-pastメソッドはかさばると思われます。また、なぜこれはFFでは機能するがIEまたはSafariでは機能しないのですか?
141 http  cookies 

7
返されたコンテンツにヘッダーContent-Type:text / htmlがある場合でも、Chrome開発ツールは応答を表示できません。charset = UTF-8
返されたコンテンツのタイプがtext / htmlの場合、Chrome開発者ツールが「応答データを表示できませんでした」と表示して応答するのはなぜですか? 開発者ツールで返された応答を確認する代替手段は何ですか?


6
重複するHTTP GETクエリキーの信頼できる位置
次のようなHTTP GETクエリ文字列の重複フィールドの動作に関する信頼できる情報を見つけるのに問題があります。 http://example.com/page?field=foo&field=bar 特に注文が維持されるかどうか。ほとんどのWeb指向言語は、キー「フィールド」に関連付けられたfooとbarの両方を含む配列を生成しますが、この点について(RFCなどで)権威あるステートメントが存在するかどうか知りたいです。RFC 3986には、3.4. Querykey = valueペアを参照するセクションがありますが、順序の解釈方法やフィールドの重複方法などについては何も述べられていません。これは、バックエンドに依存し、そのRFCの範囲ではないため、理にかなっています... 事実上の標準が存在しますが、好奇心から、それについての信頼できる情報源を見たいと思います。
137 http  uri 


1
HTTP 301と308のステータスコードの違いは何ですか?
HTTP 301と308ステータスコードの違いは何ですか? 301 (恒久的に移動):これ以降のすべてのリクエストは、指定されたURIに送信する必要があります。 308 (永続的なリダイレクト):リクエストと今後のすべてのリクエストは、別のURIを使用して繰り返す必要があります。 彼らは似ているようです。

7
HttpURLConnectionでプロキシを使用するにはどうすればよいですか?
これをしたら... conn = new URL(urlString).openConnection(); System.out.println("Proxy? " + conn.usingProxy()); 印刷する Proxy? false 問題は、プロキシの背後にいることです。JVMはWindowsでプロキシ情報をどこから取得しますか?どうすれば設定できますか?私の他のすべてのアプリは私のプロキシに完全に満足しているようです。
136 java  windows  http  proxy 


4
REST、HTTP DELETEおよびパラメーター
HTTP DELETEリクエストにパラメーターを提供することに関してRESTfulでないものはありますか? 私のシナリオでは、「本当に削除してもよろしいですか?」をモデル化しています。シナリオ。場合によっては、リソースの状態は、要求された削除が無効である可能性があることを示唆しています。おそらく、自分で削除の確認が必要ないくつかのシナリオを想像できます。 私たちが採用したソリューションは、削除リクエストにパラメーターを渡して、削除を続行してもよいことを示すことです( "?force_delete = true") 例えば DELETE http://server/resource/id?force_delete=true 私はそれがまだ落ち着いていると信じています: (a)DELETEのセマンティクスは変更されていません。ユーザーは通常のDELETEリクエストを送信できますが、409で失敗する可能性があり、応答の本文に理由が説明されています。(説明する価値がない理由で)場合によってはユーザーにプロンプ​​トを表示する理由がないため、失敗する可能性があると言います。 (b)Royの論文には、RESTの精神に反することを示唆するものは何もありません。なぜHTTPはRESTの1つの実装にすぎないので、なぜHTTPパラメータを渡すことが重要なのでしょうか。 これがRESTfulでない理由を否定する決定的な声明を誰かが私に指摘できますか? 関連する質問で、ユーザーがforce_deleteを指定しなかった場合、返されます409 Conflict-これが最も適切な応答コードですか? ファローアップ さらに調査した結果、DELETEにパラメーターを追加すると、いくつかの原則に違反する可能性があると思います。 1つ目は、実装が「Uniform Interface」に違反している可能性があることです(Royの論文のセクション5.1.5を参照)。 'force_delete'を追加することで、すでに適切に定義されたDELETEメソッドに制約を追加します。この制約は私たちだけに意味があります。 また、確認ダイアログは本当にUIの問題であり、すべてのクライアントが削除の確認を望んでいるわけではないため、「5.1.2クライアントサーバー」に違反していると主張することもできます。 誰か提案?
135 http  rest 

10
ASP.NET Coreでクエリ文字列から値を読み取る方法は?
ASP.NET Core MVCを使用してRESTful APIを1つ構築しています。クエリ文字列パラメーターを使用して、コレクションを返すリソースのフィルタリングとページングを指定します。 その場合、クエリ文字列で渡された値を読み取って、フィルター処理を行い、返される結果を選択する必要があります。 コントローラーGetアクション内でアクセスするとHttpContext.Request.Query1が返されることはすでにわかっていますIQueryCollection。 問題は、値を取得するためにそれがどのように使用されるのかわからないことです。実は、私は、例えば、 string page = HttpContext.Request.Query["page"] 問題はHttpContext.Request.Query["page"]、文字列ではなくStringValues。 とにかく、IQueryCollectionクエリ文字列の値を実際に読み取るにはどうすればよいですか?

12
レストコレクションでのページング
JSONドキュメントのコレクションに直接RESTインターフェースを公開することに興味があります(CouchDBまたはPersevereを考えてください)。私が直面している問題はGET、コレクションが大きい場合にコレクションルートでの操作を処理する方法です。 例として、Questions各行がドキュメントとして公開されているStackOverflowのテーブルを公開しています(必ずしもそのようなテーブルがあるわけではなく、「ドキュメント」のかなり大きなコレクションの具体例にすぎません)。コレクションはで利用可能になるでしょう/db/questions通常のCRUDのAPIを使用してGET /db/questions/XXX、PUT /db/questions/XXX、POST /db/questions遊びです。コレクション全体を取得する標準的な方法は次のGET /db/questionsとおりですが、それが各行をJSONオブジェクトとして単純にダンプする場合、かなり大きなダウンロードとサーバー側での多くの作業が発生します。 もちろん、解決策はページングです。道場は、この問題を解決したJsonRestStore使用の巧妙なRFC2616に準拠した拡張を介してRangeカスタム範囲部とヘッダitems。結果は206 Partial Content、要求された範囲のみを返すです。クエリパラメータに対するこのアプローチの利点は、クエリ文字列(クエリなど)を残すことです(たとえばGET /db/questions/?score>200、エンコードされます%3E)。 このアプローチは、私が望む行動を完全にカバーしています。問題は、RFC 2616が206の応答について次のように指定していることです(強調は私のものです)。 要求が Rangeヘッダフィールド(含んでいなければなりませんセクション14.35を所望の範囲を示す)、及び場合-Rangeヘッダフィールド(含まれている可能性があり部14.27を要求する条件を作るために)。 これは、ヘッダーの標準的な使用法のコンテキストでは理にかなっていますが、私が206応答を、単純なクライアント/ランダムなユーザーの探索を処理するデフォルトにしたいので問題です。 私は解決策を探すために詳細にRFCを調査しましたが、私の解決策に不満があり、SOの問題への取り組みに興味があります。 私が持っていたアイデア: 戻り値200とContent-Rangeヘッダ!-私はこれが間違っているとは思いませんが、応答が部分的なコンテンツのみであることを示すより明白な指標が望ましいです。 戻り値400 Range Required -必須ヘッダーに特別な400応答コードはないため、デフォルトのエラーを使用して手動で読み取る必要があります。これにより、Webブラウザー(またはRestyのような他のクライアント)での探索もより困難になります。 クエリパラメータを使用する -標準的なアプローチですが、永続的なクエリを許可すると、クエリの名前空間に割り込むことができます。 戻るだけ206!-ほとんどのクライアントはおかしくならないだろうと思うが、RFCのMUSTには反対したくない スペックを拡張!Return266 Partial Content -206とまったく同じように動作しますが、含まれてはならないリクエストに応答しますRangeヘッダーをます。私は266が衝突の問題に遭遇してはならないほど十分に高いことを理解しています。それは私には理にかなっていますが、これがタブーと見なされるかどうかははっきりしません。 これはかなり一般的な問題だと思います。私や他の誰かがホイールを再発明しないように、これをある種の事実上の方法で実行してもらいたいと思います。 コレクションが大きい場合にHTTP経由で完全なコレクションを公開する最良の方法は何ですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.