HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
)
第 15 章: Windows HTTP サービスの使用
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 Hilo Browser アプリケーションでは、オンライン写真共有アプリケーションである Flickr への写真のアップロードが可能になりました。この機能を提供するため、Windows HTTP サービスが使用されています。この章では、Hilo Browser でこのライブラリをどのように使用して、写真共有機能を実装しているかについて説明します。 [Share] ダイアログを通じた Flickr との連携 Hilo で Flickr に写真をアップロードする場合、Flickr の Web サーバーに対して複数の呼び出しが実行されます。これらの呼び出しは、Hilo アプリケーションの認証 (および frob (
Golangで作ったhttpdの接続数を制限してみよう
こんにちは。斎藤です。 ここ1〜2年、私は仕事でGolangを書くことが増えています。きっかけは、ITインフラをお預かりする中で、お客様のサーバにツールを置く場合でも1つのバイナリさえ置けば良いという手軽さからだったのですが、最近はScalaと並び手軽に並列処理が書けるプログラミング言語として重宝しています。 さて、今回はGolangで作ったhttpdの接続数をLimitListenerを利用して接続数の制限をしてみようというお話です。以下に紹介するお話は、Githubのリポジトリ "github.com/koemu/go-http-max-connections-demo" にデモプログラムを保存しています。Golangのビルド環境がある方は、実際にビルドしながらお試しいただければと思います。 ※Golang 1.5.1でビルドする前提で説明しています モティベーション 仕事でとあるAP
スレッドプログラミングによる HTTP/2 の実装
1 HTTP/2 @kazu_yamamoto 2 HTTP/2 ( ) HTTP/2 3 HTTP/2 4 HTTP/1.1 5 HTTP/1.1 Head-of-line 6 1 1 1 1 6 7 8 800 GET /roversync/ HTTP/1.1 Host: rover.ebay.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Referer: http://www.ebay
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
Overview - OkHttp
Overview Features Recipes Security Works with OkHttp API Change Logs Contributing OkHttp¶ HTTP is the way modern applications network. It’s how we exchange data & media. Doing HTTP efficiently makes your stuff load faster and saves bandwidth. OkHttp is an HTTP client that’s efficient by default: HTTP/2 support allows all requests to the same host to share a socket. Connection pooling reduces reque
HTML 5.2: 4.13. Common idioms without dedicated elements
Table of contents 1 Introduction2 Common infrastructure3 Semantics, structure, and APIs of HTML documents4 The elements of HTML5 Microdata6 User interaction7 Loading web pages8 Web application APIs9 Communication10 Web workers11 Worklets12 Web storage13 The HTML syntax14 The XML syntax15 Rendering16 Obsolete features17 IANA considerationsIndexReferencesAcknowledgmentsIntellectual property rights F
いまさら聞けないHTTPマルチパートフォームデータ送信 - ＳＡＴＯＸのシテオク日記
放蕩ＳＡＴＯＸさん、最近、ネットワーク関連の勉強をしておりまして、アプリケーションからPHPを叩いたりしたりしています。 リモートプロシージャ的にマルチパートフォームデータで任意のコマンドやバイナリファイルを送ったりなんかするのですが、Socketを直に使っていたりするのでHTTPのプロトコルを使って通信しないといけません。 通信周りに詳しい方にとっては「今更そんなこと……」なんて言われてしまいそうなものですが、自分のためにもマルチパートフォームデータを使う際の送信内容について、覚え書きとして書いておこうと思った次第です。 ちなみに、マルチパートフォームデータとは、HTTPのリクエストで複数のフォームデータ(マルチパート)を送るための形式(HTTPのプロトコル)です。誰でもよく使っているもので、ブラウザであるページを開いて、名前の入力＋画像ファイルのアップロード、なんてときに使われています
Lesson4：相手が信頼できることを確かめる「サーバー証明書」とは？
Lesson4では，通信相手のサーバーが信頼できるかどうかを確認するしくみを見てみよう。ここでは，サーバーがクライアントに送信する「サーバー証明書」に注目する。 証明書には「署名」が付いている サーバー証明書は，サーバーの管理者が，「認証局」と呼ばれる組織に申請して発行してもらう（図4-1）。サーバー証明書には，サーバー運営者の組織名，認証局の組織名，証明書の有効期限，サーバーの公開鍵などの情報が書き込まれている。さらに，サーバー証明書には認証局の署名が付いている。署名とは，証明書の内容をハッシュした値を，認証局の秘密鍵で暗号化したデータである。 図4-1●「サーバー証明書」と「署名」とは？ サーバー証明書は，サーバーの各種情報が書き込まれた情報で，サーバーの公開鍵が含まれている。サーバー証明書には，認証局の署名（証明書を認証局の秘密鍵で暗号化したデータ）が付いている。 [画像のクリックで
HTTP authentication
As specified in RFC 2617, HTTP supports authentication using the WWW-Authenticate request headers and the Authorization response headers (and the Proxy-Authenticate and Proxy-Authorization headers for proxy authentication). Supported authentication schemes Chrome supports four authentication schemes: Basic, Digest, NTLM, and Negotiate. Basic, Digest, and NTLM are supported on all platforms by defa
HTTP クライアントを作ってみよう(6) - Digest 認証編 -
Digest 認証 (ダイジェスト認証) 前ページでは Basic 認証を紹介し、セキュリティ面で問題があることを示しました。 その欠点を解消したのが Digest 認証です。 以下の URL では Digest 認証を行っています。 ブラウザから操作する分には Basic 認証と区別が付かないでしょうが、 認証の仕組みはちょっと複雑になっています。そのかわり、 ネットワーク上を流れるパケットを覗き見られても、パスワードがばれることはありません。 以下、仕組みを簡単に説明します。 「メッセージダイジェスト」の意味がよくわからなければ、暗号化のお話 (3) を参照してください (「ハッシュ」と「メッセージダイジェスト」は同じものと考えてください)。 まず、あらかじめサーバ側にパスワードの MD5 メッセージダイジェストを保存しておきます (ユーザ登録に相当)。 クライアントが Digest
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
HTTPサーバにJava NIOは必要か
0x00. はじめに 筆者はJava製のWAF(Web Application Firewall)、Guardian@JUMPERZ.NETの開発とメンテナンスを行っている。元は自社のシステムを守るために（そして半分趣味で）作ったものだが、数年前にこれをコアのエンジンとしてさらに拡張し、SaaS型の商用サービス「Scutum(スキュータム)」を立ち上げた。 その後順調に顧客を獲得することができ、システムリソース的にも増強が必要となる段階などを経験した。Google、mixiやはてな等、さまざまな大規模サイトのインフラエンジニアの方々がインフラ設計に関する考え方などをインターネット上で公開してくれているおかげで、初期のシステム設計時に「将来的にスケールアウト可能なシステム構成にしておくこと」が重要であるということがわかっていた。その教えに従っていたおかげで、リソースの逼迫（ちなみに今回はCP
C++ Network Library — cpp-netlib v0.7 documentation
Welcome¶ The cpp-netlib is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. It is developed by people linked to the Boost community and will at some point in the future be submitted for review into Boost. A presentation about cpp-netlib was given at BoostCon 2010,
HTTP クライアントを作ってみよう(3)
改良版を作ってみよう 前節で説明したサンプルは、一応は HTTP クライアントとして最低限の動作はしますが、 もう少し機能を追加してみましょう。 ダウンロードする URL を指定できるようにする User-Agent 情報を送る Proxy に対応する HEAD に対応する の4点を改善してみます。以下に詳しく説明します。 URL を指定できるようにする さきほどのサンプルでは http://www.cs.gunma-u.ac.jp/ にしかアクセスできませんでした。 コマンドラインで任意のURLを指定できるようにしてみます。 User-Agent 情報を送る User-Agent については User Agent統計 を参照してください。要は HTTP クライアントの自己紹介です。 User-Agent は「クライアント名/バージョン (OSなどの情報)」 という形式にすることが推奨され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2, QUIC入門
GitHub - julienschmidt/httprouter: A high performance HTTP request router that scales well
Analysis of HTTP Performance Problems
studyinghttp.net - このウェブサイトは販売用です！ - 解説 仕様書 利用 技術 である 手法 日本語訳 プログラミング リソースおよび情報
IBM Developer
