新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
HTTP vs HTTPS Test
HTTP vs HTTPS Test Encrypted Websites Protect Our Privacy and are Significantly Faster Compare load times of the unsecure HTTP and encrypted HTTPS versions of this page. Each test loads 360 unique, non-cached images (0.62 MB total). For fastest results, run each test 2-3 times in a private/incognito browsing session.
0.0.0.0にはアクセスしないこと - Qiita
はじめに この記事は2019年4月時点で調べたものをベースにしています。将来的に変わるかもしれません。 tl;dr 0.0.0.0を宛先に使うのは誤り ただしOSによっては 127.0.0.1 に到達するので支障がなかったりする 想定読者 0.0.0.0と127.0.0.1の違いをすぐに答えられない人が対象です。 ネットワークな人はわかっていることだと思うのでブラウザバックしてもらって構いません。 強い人は間違えているところコメントください。 環境 Ubuntu 16.04を利用します。 $ uname -a Linux parallels-vm 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 簡単な例 Webの文脈ではWebサーバのQu
「HTTP/3」がHTTP-over-QUICの新名称に。IETFのQUICワーキンググループとHTTPワーキンググループで合意 － Publickey
現在IETFで仕様策定が進められている、UDPをベースに効率的で高速な通信を実現するためのプロトコル「QUIC」をトラスポート層に用いる新しいHTTPの名称が「HTTP/3」になることが決まりました。 HTTP/3のベースはGoogleが開発したQUIC。IETFで標準化へ もともとQUICは、Googleが高速なHTTPの通信を実現するためのプロトコルとして2013年に発表し、同社のChromeブラウザやクラウドサービスなどに実装してきました。 QUICは、従来のHTTPでトランスポート層に用いられているTCPの代わりに、UDPを用いています。 TCPはエラー訂正機能などを備え信頼性の高い通信が可能な一方、比較的オーバーヘッドの大きなプロトコルです。そこでTCPの代わりに通信の信頼性は保証されないもののオーバーヘッドの小さいUDPを用い、独自に一定の信頼性を保つ実装を組み込みつつHTTP
httpstat.us
This is a super simple service for generating different HTTP codes. It's useful for testing how your own scripts deal with varying responses. Just add the status code you want to the URL, like this: httpstat.us/200 We'll return a response like this: HTTP/1.1 {status code} {status description} Content-Type: text/plain or application/json Content-Length: {something} {any custom response headers} {st
Ruby HTTPクライアントの比較表 - Qiita
Rubyには標準でnet/httpが入っていますが、これはちょっと低レイヤ寄りで使いづらいので、使いやすくしたHTTPクライアントライブラリが多数あります。 ありすぎてどれを選んでいいか調べていたところ、HTTPClientの作者さんによる比較スライドを見つけました： http://www.slideshare.net/HiroshiNakamura/rubyhttp-clients-comparison まとめると httpartyとrest-clientが2大人気（ソースはGemのダウンロード数とgithubのスター数。faradayはラッパーなので別枠） この2つで出来ることはほとんど同じ 違いはDigest認証（httppartyは可）、multipart post（rest-clientは可）くらい どちらもKeep-Aliveに対応していない HTTPClientはDigest
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景 WebサイトをHTTPS化する最も大きな理由は、インターネットの信頼性を維持することです。TLS技術の現状や、安全なHTTPS化に何が必要かを、ヤフー株式会社の大津繁樹氏が解説します。 「SEO対策のためには、WebサイトをHTTPS化しないといけない。」 —— そう聞かされて対応を迫られている技術者の方も多いのではないでしょうか？ 確かに、Googleは「HTTPSページが優先的にインデックスに登録されるようになります」と表明し、HTTPS化されたWebサイトが同社の検索結果で有利になると示唆しています。はたして、WebサイトのHTTPS化が必要な理由は、SEO対策だけなのでしょうか？ そして、それはGoogleという一社だけの意向で推奨されていることなのでしょうか？ こうした疑問に答
Let's Encrypt (certbot) を使ってワイルドカード証明書する！(あとちょっと) - Qiita
はじめに 最近技術書を書いて、沢山の方に読んで頂いていて大変感謝しております。 イラスト図解でよくわかる ITインフラの基礎知識 その書籍の中でも、無料で手軽に使える証明書として紹介したLet's Encrypt (certbot) ですが、唯一ワイルドカード証明書が発行できないという欠点がありました。 しかしながら以前から予告されていたように、先日やっとワイルドカードに対応したというアナウンス Let's Encrypt ACMEv2 implementation now supports wildcard certs. https://t.co/jPk8DZBr4X — Jerry Gamblin (@JGamblin) March 2, 2018 が出ましたので、早速ワイルドカード証明書を取得してみました。 ところがフツーにやろうとするとエラーになになってしまいます。 [root@l
nginxをHTTP/2対応にする方法(Chrome 51以降でも有効にする) - Qiita
CentOS6.7上にnginxでSSL設定する際にHTTP/2も設定してみましたが、Google ChromeではHTTP/2が有効にならずとても大変だったので今回の手順を記録します。 追記 2016/09/05 nginx stable(1.10以下)でHTTP/2を利用する場合、iOS SafariでPostする場合にエラーが発生する場合があります。後述参照。 追記 2016/09/30 mainlineバージョンをSRPMからビルドできました。(コメントありがとうございます。) 追記 2017/12/02 nginx側の記事でNPN/ALPN対応表（引用）更新しました。 追記 2017/12/02 各種ブラウザのNPN非対応を追記しました。 Google ChromeでHTTP/2が有効にならない理由 Google Chrome51(2016/4)で SPDY/3.1,NPNが削除
ロリポップ！が無料SSL証明書に対応しました!!!1 - Pepabo Tech Portal
ホスティング事業部の CTL(Chief Technical Lead)の@pyamaです。本記事では先日盛大にリリースいたしましたロリポップの無料独自SSL機能の裏側について関わったメンバーのリレー形式で紹介したいと思います。 Let's Encrypt提供の背景 ロリポップ！のディレクターをしています@fuchinoです。ロリポップ！のリブランディングプロジェクトやプロモーション、プロダクト周り、イベントなどを担当する、ディレクターという名の何でも屋です。 Let's Encrypt提供の背景について、少し書かせていただきます。 2014年ごろから、急激に独自SSLの需要が増加しました。Googleが常時SSL化への取り組みを強化し、推奨したことが大きな理由です。2016年、Let's Encryptが正式に提供開始されてからは、その流れは一気に加速します。 ロリポップ！では、もともと
制限と仕様からLet's Encrypt(ACMEv1)の話 - Qiita
現行のACMEv1を使ったLet's Encryptのお話。 (https://letsencrypt.org) V1は終わりましたが、V2でも概ね同じです。一応V2はひとつ制限が追加されてます、追記の3を参照。 個人が手持ちのドメインで利用するにはあまり気にすることもないですが、何度も証明書を発行しようとすると制限に引っかかってくることがあります。 https://letsencrypt.org/docs/rate-limits/ 先日Encryptを少し多めにLet'sした機会があったので、その時に色々気を使ったことをまとめておきます。 Let's Encryptにかかる制限(rate-limits) といっても、(ドメインの所有さえ確認できれば)ACMEの仕様としてかかる制限はありません。 ほとんどはACMEのプロバイダによる、証明書の発行やそれにまつわるリクエストへの量的な制限とな
Connection test
The duration of the test is between 5 and 200 seconds. You will be automatically redirected to the results page when all tests are finished. The items below are being tested. Modern addresses reachable? Running... Domain signatures validated? Running... JavaScript inactive. Please enable JavaScript in order to execute the test.
他人の書いたソフトウェアのバグへの対処例 - Qiita
はじめに 本記事は、他人の書いたソフトウェアのバグに遭遇したときにどうするかという流れを、実例を基にして、ストーリー仕立てでなるべく具体的に書きました。このようなときの対処に不慣れな人に、実際のデバッグ、バグレポート、および修正案の提出までの流れを掴んでもらうことが目的です。 バグに遭遇 筆者も参加していたLinux Advent Calendar 2016に、ある日シェルスクリプト（Bash）で作るTwitterクライアントという記事が投稿されました。twitter APIの認証に使われているOAuth1.0aとshell芸に興味があったことより、この記事を読んでみることにしました。 そこで紹介されているtweet.shというbash製twitterクライアントを試そうとしたところ、出力は次のようになりました。 いきなり何かがおかしいです。自分のtwitterアカウントに関するJSON形
GoReplayを導入して、Production環境へのリクエストを複製し、Staging環境に転送する仕組みを作った - Glide Note
結構前に作っていたんですが、いろいろと忙しくてブログに書くタイミングを失していたので年末のタイミングで紹介。 TL;DR GoReplayを利用して、Production環境のリクエストを複製し、Stagins環境、開発環境に投げる仕組みを作った インフラ構成の大きな変更無しで、手軽にProduction環境の実リクエストを複製し、開発、動作検証ができるようになった 2016年の弊社サービスのDocker化や、インフラ構成の大幅な変更、ミドルウェアのアップデート、アプリの改修時のバグ事前検知と事故防止に大いに役に立った GoReplayの説明 GoReplay Goで書かれており、バイナリを設置し、オプションを指定し実行するだけで動作する アプリが稼働しているサーバで動く。(例えばNginx+Railsが稼働しているサーバで一緒にGoReplayを動かす感じ。) libpcap を利用して
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
