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

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

5
JSON WebサービスはCSRF攻撃に対して脆弱ですか?
リクエストとレスポンスのコンテンツにJSONのみを使用する(つまり、フォームでエンコードされたペイロードを使用しない)Webサービスを構築しています。 次の場合、WebサービスはCSRF攻撃に対して脆弱ですか? どれでもPOSTトップレベルのJSONオブジェクトのない要求は、例えば、{"foo":"bar"}たとえば、400で拒否されますが、POST内容の要求は42これ拒否されるだろう。 任意POST以外のコンテンツ・タイプの要求application/json例えば400で拒否されますが、POSTコンテンツタイプの要求はapplication/x-www-form-urlencoded、したがって拒否されるであろう。 すべてのGETリクエストは安全であるため、サーバー側のデータは変更されません。 クライアントはセッションCookieを介して認証されます{"username":"user@example.com", "password":"my password"}。これは、JSONデータを使用したPOSTを介して正しいユーザー名とパスワードのペアを提供した後にWebサービスがクライアントに提供します。 補助的な質問:CSRFに対して脆弱なものはPUTありDELETEますか?ほとんどの(すべて?)ブラウザがHTMLフォームでこれらのメソッドを許可していないように思われるので、私は尋ねます。 編集:アイテム#4を追加しました。 編集:これまでのところ多くの良いコメントと回答がありますが、このWebサービスが脆弱な特定のCSRF攻撃を提供した人は誰もいません。
82 http  security  csrf 

4
DjangoビューからHTTPステータスコード204を返すにはどうすればよいですか?
ステータスコードを返したい 204 No ContentDjangoビューから。これは、データベースを更新する自動POSTに応答するものであり、更新が成功したことを示す必要があります(クライアントをリダイレクトせずに)。 HttpResponse他のほとんどのコードを処理するためのサブクラスがありますが、204は処理しません。 これを行う最も簡単な方法は何ですか?


5
AuthorizationHTTPヘッダーをカスタマイズします
クライアントがAPIにリクエストを送信するときに、クライアントを認証する必要があります。クライアントにはAPIトークンがあり、標準Authorizationヘッダーを使用してトークンをサーバーに送信することを考えていました。 通常、このヘッダをするために使用されるBasicとDigest、認証。しかし、このヘッダーの値をカスタマイズして、カスタムauth-schemeを使用できるかどうかはわかりません。例: Authorization: Token 1af538baa9045a84c0e889f672baf83ff24 これをお勧めしますか?または、トークンを送信するためのより良いアプローチはありますか?

4
HTTP範囲ヘッダー
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 を読んでいて、ファイルのダウンロードを続行する方法を見つけようとしていました。 たとえば、ファイルの長さが100バイトで、100バイトすべてがあるとします。ただし、予想されるファイルサイズがわからないため、ファイルを要求し、次のようなRangeヘッダーを指定します。 Range: bytes=100- これは有効な範囲リクエストですか?

2
fiddler HTTPMethod(GET / PUT / POST / DELETE…)列
HTTPMethod(GET / PUT / POST / DELETE ...)列をフィドラー表示に追加する簡単な方法はありますか? セッション変数を追加するためのフィドラーウィキでこれらの手順を見つけました: cols add "Client IP Address" X-CLIENTIP しかし、HTTPMethodはそれほど簡単ではないようです。 誰かがこれを行う方法を知っているか、優れたフィドラースクリプトを持っていますか?
81 http  fiddler 


5
Pythonリクエスト:Authorizationヘッダーを削除するPOSTリクエスト
Pythonリクエストライブラリを使用してAPI POSTリクエストを作成しようとしています。Authorizationヘッダーを通過していますが、デバッグしようとすると、ヘッダーが削除されていることがわかります。何が起こっているのか分かりません。 これが私のコードです: access_token = get_access_token() bearer_token = base64.b64encode(bytes("'Bearer {}'".format(access_token)), 'utf-8') headers = {'Content-Type': 'application/json', 'Authorization': bearer_token} data = '{"FirstName" : "Jane", "LastName" : "Smith"}' response = requests.post('https://myserver.com/endpoint', headers=headers, data=data) 上記のようAuthorizationに、リクエストの引数に手動でヘッダーを設定しましたが、実際のリクエストのヘッダーがありません: {'Connection': 'keep-alive', 'Content-Type': 'application/json', 'Accept-Encoding': 'gzip, deflate', 'Accept': '*/*', 'User-Agent': 'python-requests/2.4.3 CPython/2.7.9 Linux/4.1.19-v7+'}。 追加情報として、POSTリクエストをGETリクエストに変更すると、Authorizationヘッダーは正常に通過します。 このライブラリがPOSTリクエストのヘッダーをドロップするのはなぜですか?これを機能させるにはどうすればよいですか? リクエストライブラリのv2.4.3とPython 2.7.9を使用する

3
Azure App Servicesアプリケーション内のlocalhostへのリクエスト
診断情報を含むリクエストをリッスンする継続的なWebジョブがあります。 接続をテストするために、Webジョブでヘルスチェックを実行しようとしましたが、Azureアプリサービスのドキュメントごとにlocalhostにリクエストを送信できません。 以下のコードは、デプロイしたアプリケーションから接続できることを確認するために使用するコードです。 var uri = new Uri("http://localhost:8989/ping"); var response = await client.GetAsync(uri); 私はこの例外を受け取ります: System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:8989 …

2
HTMLビデオループがビデオファイルを再ダウンロード
かなり大きいHTML5ビデオがあります。Chromeも使用しています。video要素にはloop属性がありますが、ビデオが「ループ」するたびに、ブラウザはビデオファイルを再ダウンロードします。設定しましたCache-Control "max-age=15768000, private"。ただし、これによって同一ファイルの追加ダウンロードが妨げられることはありません。Amazon S3を使用してファイルをホストしています。また、s3サーバーはAccepts Rangesヘッダーで応答するため、ファイルの数百の部分的なダウンロードが206http応答コードで要求されます。 これが私のビデオタグです: <video autoplay="" loop="" class="asset current"> <source src="https://mybucket.s3.us-east-2.amazonaws.com/myvideo.mp4"> </video> 更新: 最良の解決策はAccept Ranges、元の応答でヘッダーが送信されないようにし、代わりに200 http応答コードを使用することです。ビデオを.htaccessファイル全体にキャッシュするために、これをどのように実現できますか? 前もって感謝します。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.