HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
この~pageでは、 ~IETFによる `Hypertext Transfer Protocol（ HTTP ）＠~HTTPWG/$ の 2014年に公表された~versionを成す，次に挙げる仕様に共通な内容を（日本語訳にあたり）集約する ⇒＃ `RFC7230＠~7230$, `RFC7231＠~7231$, `RFC7232＠~7232$, `RFC7233＠~7233$, `RFC7234＠~7234$, `RFC7235＠~7235$ これらは、 今や，2022年 6 月に公表された中核~HTTP仕様（ RFC9110, RFC9111, RFC9112 ）により廃用にされた。 それらの日本語訳は、 `~HTTP日本語訳 共通~page＠~HTTPcommon$にある。 ~HTTPに関係する各種 RFC の（網羅的でない）一覧, および ~HTTP全般に共通な内容（構文の表記法な
TLS • TLS (reliable) endpoint endpoint CC BY 3.0 https://www.youtube.com/user/TheWikiLeaksChannel ClientHello+ ApplicationData end_of_early_data Finished ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData
To use Content Delivery Networks as HTTP caches you need to know about the proper HTTP response headers: Which are relevant? How do they work? How to you use them? All this I try to answer in this article. The post does not claim to be exhaustive or even completely precise. In some instances, I will simplify and be opinionated for the sake of clarity, brevity and reduced complexity. This text hand
Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
A centralized routing solution for your Kubernetes deployment.
HTTP通信の機能を持ったプログラムをテストするときに、どこにアクセスするか、迷うことがある。(モックが使えるならそれがいいけど) そんなときにおすすめな、example.comとhttpbinとbadssl.comを紹介してみる。 example.com 名前がそのままだが、example.com はちゃんと動くサイトである。よくサンプル文字列として(例えばメールアドレスとかで)仕込んでたのだが、最近まで本当に生きたサイトだとは知らなかった。 亜種に example.org とか example.netもある。RFC 2606に定義されているそうで、第三者に悪影響が及ばないことを保障することができるとある。Wikipediaにも記事がある。 ただ、あくまで普通のウェブサイトであり、「403をテストしたい」といった特殊なテストには合わない。そんな人にhttpbinをおすすめしたい。 htt
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
VisualAge for JavaのWebsphereテスト環境、Apache Tomcatテスト環境双方ともに現在はHTTP/1.1サーバに対応していない。しかしながら、Tomcatのスタンドアロンのモードは4.0版からHTTP/1.1対応である。4.0版はこれまでと別のCatalinaと呼ばれるプロジェクトグループ（TomcatもCatalinaも有名な海軍機なので、その辺からこの名前がつけられたのかもしれない）が開発したものを採用したもので、まだベータ版であるが、実験的にこれを用いて、皆さんのコンピュータだけでこの継続した接続とチャンク応答を実習することができる。Tomcat 4.0は Servlet仕様書2.3版及びJSP 1.2仕様にも対応している。Tomcat 4.0のダウンロードとインストールは添付資料を参照されたい。 継続した接続に対するHTTP/1.1サーバの対応は以下
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
