NGINXのコア開発者が親会社と決別、新たに「freenginx」という名前でフォーク版を作成開始
NGINXは世界で最も使用されているウェブサーバーですが、そのコア開発者の1人がNGINXを所有している会社であるF5 Networksと対立し、NGINXの開発を離れて新たにNGINXのフォーク版である「freenginx」を開発すると発表しました。 announcing freenginx.org https://freenginx.org/pipermail/nginx/2024-February/000000.html NGINXはロシアの開発者イーゴリ・シソエフ氏によって2004年に無料のオープンソースソフトウェアとしてリリースされました。その後、ソシエフ氏はマキシム・ドゥーニン氏およびアンドリュー・アレクセーエフ氏と共同で2011年に商用サポート提供のための会社Nginx Inc.を設立。着実にシェアを伸ばし続け、2024年2月時点では世界中のウェブサーバーのうち34.1％でN
ChatGPTをぬるぬるにする🐌Server-Sent Eventsの基礎知識
単方向通信であるということと、HTTP/1.1上で動作しているのが大きな特徴です。 また、HTTP上で動作することから、通信の互換性が高く、セキュリティモデルも使いまわせるので安心です。 どんな用途と相性がいいの？ 双方向通信がしたいわけでなければ、相性の幅がとても広いです。 今回の ChatGPT のような、GPT がトークンを生成するごとに送るケースはもちろん、通知の未読件数バッジの更新、ニュース速報の表示など、サーバからイベントを送りたい時ならなんでも使えます。 HTTP/1.1で動くカラクリ SSEはHTTPのレスポンスヘッダにContent-Type: text/event-streamを指定した上で動作します。 SSEが動く流れ クライアントがサーバーに HTTP/1.1 リクエストを送信し、イベントストリームに接続します。 サーバーは、Keep-Alive 接続を使用して、T
WebAPIの独自Headerを "X-" から始めるのはありかなしか - Qiita
APIサーバーの仕様を検討している時に、headerに入れる独自パラメータの名前について一悶着（自己完結）あったので、メモ。 何を悩んだのか 例えば、URLには含みたくない secret のようなリクエストパラメータについて、独自にキー名を決めようと思います。 こんな感じ。 で、なんかいい名前ないかなぁと思ってググってたら、こんなやりとりを見つけました。 stackoverflow / Custom HTTP headers : naming conventions On June 2012, the deprecation of recommendation to use the "X-" prefix has become official as RFC 6648. このやり取りの質問とベストアンサーだけ見て「なんだって！独自ヘッダに X- をつけるのは常識じゃないの？時代遅れなの！？
Denoが大幅な方針変更を発表。3カ月以内にnpmパッケージへの対応を実現、最速のJavaScriptランタイムを目指しHTTPサーバを刷新
Denoが大幅な方針変更を発表。3カ月以内にnpmパッケージへの対応を実現、最速のJavaScriptランタイムを目指しHTTPサーバを刷新 オープンソースのJavaScript/TyeScriptランタイム「Deno」を開発するDeno Landは、「Big Changes Ahead for Deno」（Denoの方向性の大きな変更）という記事を公開し、Denoのnpmパッケージへの対応や高速化などの新たな取り組みを発表しました。 Big changes ahead for Denohttps://t.co/Q5xKz3bJLg — Deno (@deno_land) August 15, 2022 今回の発表では、npmへの対応、最速のJavaScriptランタイムを目指す、企業向けサポート、という3つの大きな取り組みが示されています。 3カ月以内にnpmパッケージをインポート可能に
Webサイトを離れたときにデータを送る Page Unload Beacon (Pending Beacon API) - ASnoKaze blog
Webサイトを離れたときにサーバにデータを送れるようにする「Page Unload Beacon」という仕組みが、W3CのWICGで議論されています。 既存のページのライフサイクル(unloadイベントやbeforeunload)で、サーバにデータを送ろうとしても処理されないことがあります。そのため、ページのunload時にビーコンを送るように登録できるようにするのが「Page Unload Beacon」です。 最新のChrome Canaryでとりあえず動くっぽいので、触ってみる (まだ動作するだけで、一部仕様と異なります) Page Unload Beacon デベロッパーツールから次の通り実行して、Beaconを登録しておきます。今回はGETリクエストとPOSTリクエストのビーコンをそれぞれ登録。 getbeacon = new PendingGetBeacon("http://e
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei
この記事は Nikkei Advent Calendar 2020 20日目の記事です。 日経電子版Webチームの阿部です。今回はHTTP/2の目玉機能の1つであったServer Pushの事実上の終焉と、現在ChromeチームやFastly社が実験中の103 Early Hintsについて、日経電子版Webでの取り組みを紹介させていただきます。 HTTP/2 Server Push HTTP/2 Server PushはHTTP/2で策定された、一言で言ってしまうと「必要なリソースがリクエストされる前にサーバーからクライアントに送ってしまおう」という技術です。 これによりクライアントがリクエストするリソースを先回りしてサーバーが送ることで、必要なリソースが揃うまでにかかる時間を短縮できるため、パフォーマンスの向上が期待されていました。 Server Pushの問題点 一方、サーバーからク
Web Application開発に10080番ポートは使ってはいけない
要約 現在最新のGoogle Chormeで10080番ポートが使用できなくなった Firefoxではすでにブロック済み NAT Slipstreaming v2攻撃への対応のため ブラウザからアクセスするサーバを建てる場合は10080以外のポートにするべき 回避方法は一応ある Chrome 91以降は10080番ポートがブロックされる Google Chormeの91 (2021/05/25 リリース)から10080番ポートへのサーバに接続できなくなります。 例えば Google Chrome 90だと以下のように10080番のポートを受け付けるサーバにアクセスできますが、91以降だとアクセスできなくなります % python -m http.server 10080 Serving HTTP on 0.0.0.0 port 10080 (http://0.0.0.0:10080/) .
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
Webブラウザ上で純粋なHTTPだけで単方向リアルタイム通信を可能にするHTTPのストリーミングアップロードが遂にやってくる - nwtgck / Ryo Ota
Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
簡単にSSL証明書を取得可能＆シンプルな設定ファイルでHTTP/3も利用できるGo製ウェブサーバー「Caddy」
ウェブサーバーとして有名なソフトウェアはApacheやnginxですが、設定が難しいと感じる人も少なくないはず。Google発のプログラミング言語「Go」で開発された「Caddy」は、最低限の設定でSSLによる暗号化やHTTP/3での通信も可能なウェブサーバーです。 Caddy 2 https://caddyserver.com/v2 CaddyはUbuntuやCentOSなどのLinuxで利用可能。今回はUbuntu 18.04にCaddyをインストールしてみます。 下記コマンドを実行すれば、Caddyをインストールすることができます。 echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" \ | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list sudo apt update s
HTTPメッセージに署名をするSignatureヘッダの標準化 - ASnoKaze blog
HTTPメッセージに署名をするSignatureヘッダを定義する「Signing HTTP Messages」という仕様が提案されています。 HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。例えば、AWS APIを叩く際に利用する「Signature Version 4 Signing」や、OAuth2.0 DPoPなどでHTTPメッセージへの署名が行われています。 その他にも、WebPackagingで使用される「Signed HTTP Exchanges」といったところでも署名が行われています。 一方でTLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセー
不正アクセスからサーバを守るfail2ban。さくらのクラウド、VPSで使ってみよう！ | さくらのナレッジ
こんにちは。さくらインターネットの前佛です。 今回は、サーバのログファイルを自動スキャンして、悪意のある SSH 通信を自動遮断するツール fail2ban の概要と使い方をご紹介します。 日々、不正アクセス インターネット上のサーバは、SSH や HTTP など、公開しているポートに対する不正アクセスの試みに日々晒されています。不正アクセスは悪意を持った人からの攻撃だけではありません。マルウェアやワームなど、いわゆるボットからの攻撃にも日々晒されているのです。 そのため、誰でもアクセス可能なパブリックな環境にサーバを公開する場合、セキュリティに対して細心の注意を払う必要があります。 たとえば、近年話題になっている Linux 向けのマルウェアとしては XOR.DDoS が有名です。これは root ユーザのパスワードに対する総当たり攻撃（broute-force attach）を試みます
これからドンドン使われていくSNIについて
SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。 しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。 そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。 そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host
SOCKSプロキシとHTTPプロキシの違いについて勉強してみた | DevelopersIO
はじめに サーバーレス開発部@大阪の岩田です。 先日接続元IPアドレスをクラスメソッドのGIPに制限した検証環境を利用してAPIのテストを行なっていたところ、リモートワーク中のメンバーが検証環境に接続できないという状況が発生しました。 下記の記事で紹介されているように、クラスメソッドではSOCKSサーバーが構築されているので、VPN経由で社内NWに接続し、SOCKSサーバーをプロキシとして利用すれば本来リモート環境からでも検証環境が利用できるはずです。 VPN利用者のためにdelegateでSOCKSサーバーを立ててみました 最初はcurlコマンドのオプションに--proxyを付けてプロキシサーバーを指定するようお願いしたのですが、--proxy http://proxy.example.com:xxxxのような指定を行なっていたようで、問題が解決しませんでした。 結局--proxy so
処理中のPOSTリクエストを別のサーバで引き継ぐPartial POST Replayについて - ASnoKaze blog
なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。 スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。 やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。 「HTTP Partial POST Replay」では、ユーザの接続
結局ライブラリはCDNから読み込むのとnpm installして自前配信のどっちが良いのか？(意見も求む) - Qiita
結局ライブラリはCDNから読み込むのとnpm installして自前配信のどっちが良いのか？(意見も求む)JavaScriptnpmTypeScriptCDNwebpack 執筆の動機 JavaScriptやらTypeScriptやらでコードを書いている際に、利用する各種ライブラリをCDNで読み込むこともnpm installしてからwebpackで固めて自前配信することも両方できることが多いと思うのだが、どちらを選択すべきなのだろう？ 昔はCDN最強説があったし、私もそれで納得していたが、ここ数年で状況が変わったように思う。とはいえ、人によって意見が異なる部分だと思うので、重要技術について触れながら私なりに考察する。 考慮する観点 ユーザーの実行速度(実行速度) ユーザーがWebページを訪問した際に、応答速度が遅いと逃げられてしまうだろう。お客さんがいないとサービスは成り立たない。重要な
SXG（Signed HTTP Exchanges）始めました
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部でCDNの仕事をしている大津と申します。他にも社内セキュリティガイドラインの作成や、Node.jsのサポートもしています。 今週、4月17・18日に東京で開催するAMP Conf 2019 において、「Maximize Yahoo! JAPAN 's UX with AMP and Signed HTTP Exchanges」（AMPとSigned HTTP Exchangesを使ってYahoo! JAPANのUXを最大化する）という発表を行います。プレゼンでは、最初に駒田がYahoo! JAPAN全体とYahoo!トラベルの取り組みについて、次に私がSXGシステムの技術解説、最後に宗像がYahoo!検索の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
