The headers we don't want
Let’s look at the unnecessary headers and see why we don’t need them, and what we can do about it. Vanity (server, x-powered-by, via) You may be very proud of your choice of server software, but most people couldn’t care less. At worst, these headers might be divulging sensitive data that makes your site easier to attack. Server: apache X-Powered-By: PHP/5.1.1 Via: 1.1 varnish, 1.1 squid RFC7231 a
How to Think About HTTP Status Codes
Hi, I’m Mark Nottingham. I usually write here about the Web, protocol design, HTTP, and Internet governance. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social Thursday, 11 May 2017 Standards HTTP There’s more than a little confusion and angst out there about HTTP status codes. I’ve received more than a few e-mails (and IMs, and DMs) over the years from stressed-out developer
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTP キャッシュを使用して不要なネットワーク リクエストを防止する | Articles | web.dev
HTTP キャッシュを使用して不要なネットワーク リクエストを防止する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 ネットワーク経由でのリソースの取得には時間とコストがかかります。 サイズの大きいレスポンスの場合、ブラウザとサーバーの間で何度もやり取りする必要があります。 重要なリソースがすべてダウンロードされるまで、ページは読み込まれません。 限られたモバイルデータ プランでサイトにアクセスしている場合、不要なネットワーク リクエストはすべてユーザーのお金の無駄使いです。 不要なネットワーク リクエストを回避するにはどうすればよいでしょうか。ブラウザの HTTP キャッシュは防御の最前線ですこれは必ずしも最も強力で柔軟なアプローチではなく、キャッシュに保存されたレスポンスの存続期間を制御することは限られていますが、効果的であり、すべてのブラウザでサポ
Cookie関連の最新動向 (2016年) - Qiita
はじめに 去年ぐらいからCookieに関する議論が活発に行なわれているように感じます。そこでCookie関連の最新動向について仕様の観点から幾つか列挙します。 Deprecate modification of 'secure' cookies from non-secure origins Cookie Prefixes Same-site Cookies A Retention Priority Attribute for HTTP Cookies Content Security Policy: Cookie Controls GoogleのMike West氏による提案がほとんどです。議論はIETFのHTTPbis WGやW3Cで行なわれており将来的には正式に標準化されるものもあるでしょう。 また、幾つかはChromeへの実装が進められています。 (間違いなどありましたらご指摘下さ
キャッシュシステムのオリジンサーバアクセスの効率化と Apache Traffic Server
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。システム統括本部プラットフォーム開発本部配信プラットフォーム部の大久保諒です。 過去に何度か紹介している通り、ヤフーでは静的コンテンツのキャッシュを行うためにオープンソースの HTTP プロキシサーバである Apache Traffic Server (以下 ATS) を用いて行っています。 Yahoo! JAPAN における HTTP/2 への取り組み ヤフーの画像配信システム（CDN）の紹介 さて、 ATS のような HTTP キャッシュを行うサーバにおいて、短時間である一つのオブジェクトに対する大量の HTTP リクエストが来た際に使用できるキャッシュがない場合、オリジンサーバの負荷が増大する問題が存在します。
GitHub - shekyan/slowhttptest: Application Layer DoS attack simulator
Disclaimer Any actions and or activities related to the code provided is solely your responsibility.The misuse of the information in this website can result in criminal charges brought against the persons in question. The authors will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this tool to break the law. SlowHTTPTest Slo
Studying HTTP
RFC(Request For Comments) 2616をはじめとした、HTTP(Hypertext Transfer Protocol)に関する文献などを紹介し、HTTPやWWW(World Wide Web)に関連する技術についての知識を深めるためのサイトです。About [Studying HTTP] 当サイトは、RFC 2616をはじめとした、HTTPに関する文献などを紹介し、HTTPやWWWに関連する技術についての知識を深めるためのサイトです。 当サイトを初めてご利用になる方は、Studying HTTP : Helpをお読みいただき、記述の内容にご同意の上、ご利用下さい。 2014.11.26 更新 当サイトへのご連絡は、現在メールのみとなっております。 Main Contents HTTP Status Code HTTP/1.1仕様書などで定義されているHTTPステータ
Configure proxy protocol support for your Classic Load Balancer - Elastic Load Balancing
Configure proxy protocol support for your Classic Load Balancer Proxy protocol is an internet protocol used to carry connection information from the source requesting the connection to the destination for which the connection was requested. Elastic Load Balancing uses proxy protocol version 1, which uses a human-readable header format. By default, when you use Transmission Control Protocol (TCP) f
[メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法
HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か（ピアがメッセージの処理を開始した否か）を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下本題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト／レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート 吉田 啓二 2013年11月30日（土）に開催された「HTML5 Conference 2013」の、エヌ・ティ・ティ・コミュニケーションズ株式会社・小松健作さんによるセッション「WebSocket, WebRTC, Socket API,…最新Webプロトコルの傾向と対策」の内容をご紹介します。 最新のWebプロトコルが続々と誕生 1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。その後、HTML5という言葉が出てきてから、WebSocketやSPDY、HTTP/2.0、WebRTC、Raw Socket API、SCTP over UDP、QUICといった
Head-of-line blocking - Wikipedia
Head-of-line blocking (HOL blocking) in computer networking is a performance-limiting phenomenon that occurs when a line of packets is held up in a queue by a first packet. Examples include input buffered network switches, out-of-order delivery and multiple requests in HTTP pipelining. Network switches[edit] Head-of-line blocking example: The 1st and 3rd input flows are competing to send packets t
nginx-1.1.x で httpなupstreamにもkeepaliveができるようになったので検証してみた - blog.nomadscafe.jp
画像配信など大量にアクセスを捌く際にちょっと気になっていたhttpなupstreamとkeepaliveできない件が、nginx-1.1系でできるようになったので試してみた 今回keepaliveできるようになったのは↑のbackendと通信するところ。 本家のドキュメントはこちら http://nginx.org/en/docs/http/ngxhttpupstream_module.html#keepalive keepalive機能を使うには、以下のように設定します http { upstream backend { server 127.0.0.1:5000; keepalive 16; } server { listen 8080; server_name localhost; location / { proxy_http_version 1.1; proxy_set_head
http_load
http_load - multiprocessing http test client Fetch the software. http_load runs multiple http fetches in parallel, to test the throughput of a web server. However unlike most such test clients, it runs in a single process, so it doesn't bog down the client machine. It can be configured to do https fetches as well. You give it a file containing a list of URLs that may be fetched, a flag specifying
HTTP/1.1 just got a major update.
The IETF just published several new RFCs that update HTTP/1.1: RFC 7230: Message Syntax and Routing RFC 7231: Semantics and Content RFC 7232: Conditional Requests RFC 7233: Range Request RFC 7234: Caching RFC 7235: Authentication RFC 7236: Authentication Scheme Registrations RFC 7237: Method Registrations RFC 7238: the 308 status code RFC 7239: Forwarded HTTP extension These documents make the ori
HTTP/2.0を捨て、より完璧なプロトコルを - W3C WGでVarnish開発者が提案
W3C HTTPワーキンググループのメーリングリストに「Please admit defeat (was: Our Schedule)」というメールが投函された。メールを投函したのは高速キャッシュサーバVarnishの開発者でありFreeBSDのカーネル開発者でもあるPoul-Henning Kamp氏。不完全な状態のHTTP/2.0を公開することはさまざまなリソースの無駄であること、HTTPのコンセプトをよりシンプルにして暗号処理やプライバシなどの問題を解決した、しっかりしたプロトコルを策定してから公開すべきだと提案している。 HTTP/2.0はGoogleの開発したSPDYと呼ばれるプロトコルをベースとした次世代のHTTPプロトコル。現在策定が進められている段階にあり、順調にいけば2015年には正式なプロトコルとして策定される見通し。しかし現在策定が進められているHTTP/2.0はいく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
go 1.8 net/http timeouts
httpbin.org
Automatic and Dynamic Configuration of Data Compression for Web Servers | USENIX
H2O - the optimized HTTP server
