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の話をし
【 この~RFCは、 今や，`現在の~HTTP中核~仕様＠~HTTPcommon#core-specifications$（ ~RFC 9111 ）により廃用にされた。 】 ◎要約 ~HTTP（ Hypertext Transfer Protocol ）は、分散型の協調的な~hypertext情報~system用の、`~stateless$な~app~levelの~protocolである。 この文書は、 ~HTTP~cacheと~~関連の［ ~cacheの挙動を制御する／ ~cache可能な応答~messageを指示する ］各種~headerを定義する。 ◎ The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hyp
もちろん、パフォーマンス最適化の至言「二度測ってから切れ」が適用されます。おっと、いや、これは大工の格言でしたが、しかし私たちにも同様に役立ちます。 Content Body ETag フィルタ 私たちが見る最初のアプローチは、ページコンテンツすなわちMVCのViewに基づくETagトークンを生成するサーブレットフィルタの作成です。一見したところ、このアプローチで得られるパフォーマンスの向上は直感的でないように思えるかもしれません。私たちは相変わらずページを生成しなければなりませんし、それにトークンを生成する計算処理が加わります。しかし、このアイデアは転送量を減少させるためのものなのです。クライアントが地球の反対側からアクセスしている時など待ち時間の大きな状況で、このアプローチは特に有益です。私は、東京のオフィスで利用されるアプリケーションをニューヨークのサーバにホスティングしているケース
Chunked Transferとは 一般にHTTP KeepAliveを利用するには、レスポンスのボディがどこで終わり、次のレスポンスがどこから始まるかをクライアントが知る必要があります、そのためHTTP/1.0ではKeepAliveを行う為にボディの長さをContent-Lengthをヘッダに入れなければなりませんでしたが、サイズを測るためにデータをすべてメモリに読み込むなどの処理が必要になり、レスポンス開始までの時間もかかります。（一般的なアプリケーションにはあまり影響がありませんが） そこでHTTP/1.1ではChunked Transferという仕組みが入っていて、事前に全体のレスポンスの長さが分からなくても、chunk=固まり毎にサイズを記してレスポンスを返していき、最後に0byteと送信することで、コンテンツの切れ目がわかるようになっています。 HTTP/1.1 200 OK
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Recently I rewrote some of our code that used LWP::UserAgent to use Furl instead, and have been observing more than 5x increase in performance (the CPU time spent for each HTTP request in average has dropped 82%). The fact clearly shows that if you are having performance issues with LWP::UserAgent it is a good idea to switch to Furl. And here are my recommendations when doing so: use the low-leve
巷でとっても速くて便利だねこれってなってる HTTP Client であるところの Furl の簡単なつかい方を紹介します。 そもそも Furl は何かっていうと、perl には LWP っていう超高機能な HTTP Client があって、これがデファクトになってるんですね。 でも、それって結構昔からあって、かつ重厚長大なモジュール群なので結構遅いわけです。とくに CPU 使用率が高い。 そんなわけで、libcurl ぐらい速くて軽い HTTP Client があるといいよねってことで開発されたのが Furl です。 読み方は ふぁーる。 use strict; use warnings; use 5.0100; use Furl; my $furl = Furl->new(agent => 'Madoka-Magica/chu-2'); my $res = $furl->get('ht
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP
bulknews.typepad.com Tatsuhiko Miyagawa's blog to discuss mostly tech and nerdy stuff. If the server environment supports it the client will automatically run asynchronous and allow the server to handle more requests while waiting for the client. In environments such as CGI and FastCGI the client will simply fallback to blocking until it is finished. Multiple client requests will always be handled
Add, Replace and Filter HTTP request headers. Modify Headers allows modification of the HTTP request headers sent to web servers. This addon is particularly useful for Mobile web development, HTTP testing and privacy. For a guide on HTTP request headers, look at this W3C page: http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html Please DO NOT post support requests or issues here. To make suggestions
丸山不二夫 稚内北星学園短期大学 経営情報学科 TEL 0162-32-7511 FAX 0162-32-7500 1995年 8月 7日 Contents はじめに wwwの成長 wwwは我々に何をもたらすか？ wwwサーバを立ち上げよう 本コースの目標と課題 実習環境 演習課題 Mosaic まずは、Mosaicから anonymous ftp 圧縮と解凍 tarコマンド Mosaicのリソース設定 External Viewerとは? Mosaicをツールとして使う 演習課題 CERN httpd リソースの取込み コンパイル インストール confファイルの設定 httpdを立ち上げる root権限でのhttpdの起動 ホーム・ページを作成する ユーザのページ作成を可能とする 演習課題 External Viewer MIME types = Media types Vie
スイスのCERN（ヨーロッパ素粒子研究所）において、Tim Berners-LeeがHTMLと共にHTTPの基礎を考案。WWW（World Wide Web）システムと名づける
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く