A simple HTTP Request & Response Service. Run locally: $ docker run -p 80:80 kennethreitz/httpbin
Webプログラムの開発では、クライアンがどのようなパラメータを送信し、サーバーがどのようなレスポンスを返しているのか正確に理解している必要があります。 今回詳細する「httpbin」はこのようなHTTPリクエストとレスポンスの確認に便利なWebサービス&ソフトウェアです。Python製のオープンソースソフトウェアで、ローカルにインストールして使用することもできますが、基本的には以下の公式サイトを利用するのが簡単です。 http://httpbin.org https://httpbin.org http://eu.httpbin.org https://eu.httpbin.org https://hub.docker.com/r/kennethreitz/httpbin/ 上記URLに対してさまざまなパラメータを追加したHTTPリクエストを送信すると、クライアントのIPアドレスやユーザー
サイズの大きなファイルをアップロードしようとするとタイトルのエラーが出るので、その対処方法。 nginx.conf まずはnginx.confファイルに「client_max_body_size 20M;」を追加。 私はリバースプロキシを利用しているので、2箇所に記述。 server { listen 80; server_name blog.10rane.com; client_max_body_size 20M; # 413 Request Entity Too Large ..... server { listen 8080; server_name blog.10rane.com; client_max_body_size 20M; # 413 Request Entity Too Large ..... php.ini php.iniは3箇所の変更。 # emacs /etc/p
HTTP の Access-Control-Allow-Credentials はレスポンスヘッダーで、サーバーがオリジンをまたいだ HTTP リクエストに資格情報を添付することを許可するかどうかをブラウザーに指示します。 資格情報にはクッキー、TLS クライアント証明書、ユーザー名とパスワードを含む認証ヘッダーなどがあります。 デフォルトでは、これらの資格情報はオリジンをまたぐリクエストでは送信されません。そうすると、サイトが クロスサイトリクエストフォージェリー (CSRF) 攻撃に対して脆弱になる可能性があります。 クライアントは、サイト間リクエストで資格情報を添付することを、いくつかの方法で要求することをできます。 fetch() を使用する際に credentials オプションを "include" に設定する。 XMLHttpRequest を使用する際に、 XMLHttpR
このページはコミュニティーの尽力で英語から翻訳されました。MDN Web Docs コミュニティーについてもっと知り、仲間になるにはこちらから。 g#પView in English �s પAlways switch to English Cookie(ウェブ Cookie、ブラウザー Cookie とも呼ぶ)は、サーバーがユーザーのウェブブラウザーに送信する小さなデータです。ブラウザーは Cookie を保存したり、新しい Cookie を作成したり、既存の Cookie を変更したり、後でリクエストされたときに同じサーバーにそれらを送り返したりすることができます。 Cookie により、ウェブアプリケーションは限られた量のデータを格納し、状態についての情報を記憶することができます。HTTP プロトコルは既定ではステートレスだからです。 この記事では、Cookie の主な用途を調べ、
Accept-Encoding: gzip Accept-Encoding: compress Accept-Encoding: deflate Accept-Encoding: br Accept-Encoding: zstd Accept-Encoding: dcb Accept-Encoding: dcz Accept-Encoding: identity Accept-Encoding: * // 複数のアルゴリズムを品質値で重み付けする構文: Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5 ディレクティブ gzip Lempel-Ziv coding (LZ77) と 32 ビット CRC を用いた圧縮形式です。 compress Lempel-Ziv-Welch (LZW) アルゴリズムを用いた圧縮形式です。 deflate zlib
Intro リファラはリンクなどでページを遷移する際に、遷移元の URL をリクエストの Referer ヘッダに載せる仕様である。 この付与はブラウザが自動で行うため、場合によっては非公開として扱っている URL が意図せず漏れることがある。 この挙動を制御することができる、Referrer-Policy ヘッダについて解説する。 Referer or Referrer 本来の英語としては RefeRRer が正しいが、HTTP Header ではスペルミスした RefeRer が互換性を保つためそのまま使われている。 しかし、新しく定義された Referrer-Policy は、正しいスペルが採用されている。 Referer ヘッダ 例えば https://example.com/index.html に貼られたリンクから https://blog.jxck.io に遷移する場合を考え
Web ブラウザーは通常 HTTP 要求の Referer: ヘッダーに参照元ページの URL を入れますが (あるいは document.referrer で参照元ページの URL を取得できますが)、 Web サイト側でこれを制御したいことがあります。 例えば、次のような場面が想定されます。 URL にユーザー名や秘密の ID などを含めざるを得ない時は、プライバシーやセキュリティーの観点から、この URL を外部に漏らしたくありません。 社内システムに URL を貼りたいことがありますが、社内システムの URL を外部に漏らしたくありません。 Web アプリケーションの開発用サーバーは、その所在を外部に漏らしたくありません。 投稿者と友達のみに公開される SNS の投稿にリンクが含まれる時、その個別 URL を漏らしたくありません。 (SNS 全体の URL が漏れることは問題ありま
サーバーからブラウザに返してくるコードのことをステータスコードといいますが、これには 100番台 案内(インフォメーション) 200番台 正常処理 300番台 移転通知 400番台 (クライアントにおける)処理失敗 500番台 サーバーエラー があり、400番台と500番台がいわゆるエラーコードとなります。正常処理である200番台は通常ブラウザに表示されることはありませんので、ここでは300番台~500番台までの主なステータスコードについてのみ取り上げます。
HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードである。RFC 9110によって定義され、IANAがHTTP Status Code Registryとして管理している。また、インターネット標準とはなっていないが「標準への提唱 (英: Proposed Standard)」段階のものや、その他の状態のステータスコードも存在する。以下に一覧を示す。 リクエストは受け取られた。処理は継続される。 100 Continue 継続。クライアントはリクエストを継続できる。サーバがリクエストの最初の部分を受け取り、まだ拒否していないことを示す。 例として、クライアントがExpect: 100-continueヘッダをつけたリクエストを行い、それをサーバが受理した場合に返される。 101 Switching Protocols プロトコル切
perlでのスクレイピング関連をメモしていきたいと思います。 まずスクレイピングするときに行なう処理は、ページを取ってくることです。 普段は、URLをブラウザのURL欄に入力し、ブラウザがHTTPでサーバにアクセスしてページを取得しています。 この処理をperlで行なうようにします。 使用するモジュールは、次の二つがあります。 LWP::Simple LWP::UserAgent これらのモジュールは、ブラウザと同様にHTTPでサーバにアクセスしてページを取得する機能があります。 それぞれの使用例は下記のようになります。 #!/usr/bin/env perl use strict; use warnings; use LWP::Simple; my $url = 'http://yahoo.co.jp/'; # LWP::Simpleの「get」関数を使用 my $html = get(
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
Appleがキーノートなどの配信に使っているのがHTTP Live Streamingと言われるプロトコルです。特別なプロトコルではなく、HTTPを使っているのがメリットですが、サポートしているブラウザがSafariくらいというのが難点です。 そこで使ってみたいのがhls.jsです。JavaScriptで作られたHTTP Live Streamingクライアントです。 hls.jsの使い方 設定も用意されています。エラーが出ても自動で回復してくれます。 Google Chromeでも動きます。10秒前後に動かすといったアクションもJavaScriptからできます。 hls.jsを使えばモダンなブラウザであればHTTP Live Streamingを提供できるようになります。良い動画配信プロトコルが見つかっていなかった方はhls.jsを使ってみてはいかがでしょう。 hls.jsはJavaSc
エンジニアのふとしです。 ネットをしていて、以下のような文言に遭遇することはないでしょうか。 404. that’s an error. この状態を見た親から「インターネットが壊れた!」と連絡がきたことがあるので、簡単に説明しようと思います。 普段インターネットをする際には意識しないかもしれませんが、この数字はそれぞれに意味が存在する「HTTPステータスコード」と呼ばれるものです。 ウェブサーバとブラウザの仕組み インターネット経由で情報を得る場合、ブラウザ(IEとかChromeとか)がサーバからページを取得しているというのは、みなさんなんとなく知っているかと思います。 サーバはリクエストに対しHTML形式でデータを返す みなさんのブラウザからサーバに「このページが見たいよ」というリクエストが送られると、サーバはHTML形式でデータを返します。 HTML形式はブラウザが解析できるファイル形
HTTPヘッダー(Request・Response)を確認したい時のツールを探してみました。結果、標準ツールが十分強力であり、Proxyタイプまで使うと何でもありな勢いな事がわかりました。HTML5/CSS3/JavaScript時代だから、これぐらいないと開発も大変ですよねぇ。 ブラウザ標準 個人的に、Chromeだけ目的ピッタリが見つからなかったのですが、どのブラウザも標準ツールが充実しています。機能がありすぎるぐらい。 InternetExplorer :[F12] > ネットワーク IE9からついてる開発者ツールの1機能。高機能です。取得結果をXML保存も出来ます。 参考:使ってみよう! F12-IE9 開発者ツール – HTTP キャプチャ機能 Firefox :Ctrl-Shift-K 4以降で導入されたWebコンソール機能。表示も綺麗で便利。保存は出来ないみたいですが、十分で
サイトを運営していると、サイト内のページの移動や削除、またはサイト自体の移転をすることがあります。その場合、リダイレクトという処理を用いて新たなページに転送を行いますが、正しい知識と手順を以って対応しなければ、検索順位の下降、ページランクやドメインエイジの喪失といったSEO的なペナルティを招いてしまいます。 そこで、そのようなペナルティを受けないために、ページ移動・サイト移転時の正しいリダイレクトの設定方法と、代表的なリダイレクトの種類やその実装方法をご紹介します。 リダイレクトの種類 リダイレクトには、HTMLやJavaScriptといったクライアントサイドプログラム、PHPやPerlといったサーバサイドプログラム、あるいは.htaccessの設定変更を行う等、様々な対応方法があります。そのうちのいくつかを、実際のサンプルソースとともに解説します。 metaタグによるリダイレクト hea
Androidでは様々な機能を利用できますが、 今回は単純なHTTP通信を行ってみたいと思います。 Yahoo! JAPANにHTTPでアクセスをして取得できるHTML情報を そのままTextViewに反映させてみます。 HttpCheckActivity .java public class HttpCheckActivity extends Activity { private static String URL = "http://www.yahoo.co.jp/"; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); // リスナーの設定 findViewById(R.id
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く