HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、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への実装が進められています。 (間違いなどありましたらご指摘下さ
HTTPからMQTTへ - IBMが提唱するモノとモノがつながる時代に最適化したプロトコル&アプライアンス | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ ビッグデータ ＞ Special ＞ HTTPからMQTTへ - IBMが提唱するモノとモノがつながる時代に最適化したプロトコル&アプライアンス ビッグデータ ビッグデータ記事一覧へ [Sponsored] HTTPからMQTTへ - IBMが提唱するモノとモノがつながる時代に最適化したプロトコル&アプライアンス 2013年12月13日(金) リスト クラウド、モバイル、ソーシャル、そしてビッグデータ。4つのトレンドが今、エンタープライズITの世界に大きな変化をもたらそうとしている。さらに、これらと密接に関係する「モノのインターネット(Internet of Things)」や「M2M(Machine-to-Machine)」の胎動も始まった。あらゆる"モノ"に埋め込まれたセンサー同士が会話することで、これまで想像もつかなかったような
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Best HTTP Clients for Mac in 2021
This article has been just updated: January 4, 2021 Web developers and server administrators need many different tools in their toolkit, and a reliable HTTP client with an assortment of useful features is among them. In this article, we introduce the top 7 best HTTP clients for Mac in 2024. What Are HTTP Clients and Who Needs Them? HTTP clients are software applications that can send specific HTTP
いしなお! - Amazon WebサービスにHTTP/1.1でアクセスするとゴミが出る
_ Amazon WebサービスにHTTP/1.1でアクセスするとゴミが出る Zend_Http_Clientをincubatorバージョンに変えてテストしていたら、Zend_Service_Amazonの動作がおかしい*1。なんでかなーと原因をたどっていったら、Amazon WebサービスへのリクエストがHTTP/1.0からHTTP/1.1に変わったことが原因だった。 以下再現コード。HTTP/1.1でのリクエスト。 $socket = fsockopen('webservices.amazon.co.jp', 80); fwrite($socket, "GET /onca/xml?ResponseGroup=Request&SubscriptionId=[Subscription ID]&Service=AWSECommerceService&Operation=ItemLookup&
cyano: HTTPSの認証ページから認証後、HTTPのページへセキュリティーの警告無しにリダイレクトする方法
普通に考えると、パスワードを認証後のHTTPレスポンスヘッダ(*1の部分)で Location: http://www.exmaple.com/logined.html とかすればいいんじゃないの？と思うのですが、そうするとIEで「セキュリティーで保護されていないページに移動しようとしています」というような警告ダイアログが出てきてしまいます。 そんな警告ダイアログが出るのはユーザーフレンドリーじゃないので、それを防ぐ方法。 解決方法は簡単で、レスポンスヘッダで対応できないならレスポンスボディーで対処すればOK（Yahoo!なんかもこの方法を使っているようです）。たとえば、認証後、*1のところで以下のようなHTMLを返してあげれば、ブラウザがHTTPなページにリダイレクトしてくれるわけです。 <html> <head> <meta http-equiv="refresh" content="
リダイレクト時の Location ヘッダに絶対 URL を設定する方法 : 管理人@Yoski
ついにこのブログもフィードメーターの人気度＝星2つに落ちてしまいました。。。 自分のツールにも見放されるくらいブログで情報発信してなかったと反省。 ・・・また少し技術的なtipsなども交えていろいろ書いていこうと思います。 ということで少し以前に話題になっていた「POST後はリダイレクトした方が吉:phpspot開発日誌」についてのメモ的エントリでも。 ブラウザのバックボタンで前のページに戻れることはユーザーにとっては既に常識化(?)されているので、私もほとんどの場合 POST 後にリダイレクトを行っています。 ＃そのほうがロジックと画面も整理しやすいので。 ただ、リダイレクト = Location ヘッダには「絶対URL」という大きな壁があり、みなさんどうしているんだろうと興味津々。 参考：[Studying HTTP] HTTP Header Fields URLやポート番号が決まって
メッセージ。 - ぼくはじぶんのあたまがおかしくなったのかとおもいました
[[http://b.hatena.ne.jp/entry/http://neta.ywcafe.net/000552.html はてなブックマーク - ステータス200なのに「その商品はありません」]] きょうぼくは、はてなブックマークをよんで、「これはおかしい」と思うぶんしょうをみつけました。それなのにみんなは、「さんこうになる」とか「べんきょうになる」とかいっていて、ぼくは「みんなどうしたんだ。目をさませ！」と思いました。 ぼくはじつは、はてなのあかうんとを持っているので、はてなブックマークはあまりつかったことがないけれども、それでも「みんな目をさませ！」とつたえたかったので、はてなブックマークをつかって「それはおかしいんじゃないの？」とかきました。 でもそれはうまくかけていないような気がしたので、やっぱりもともとの人のブログサイトに、コメントすることにしました。でも、コメントをした
200 Blog Not Found : 404 Blog Not Found
2006年03月16日22:48 カテゴリ一日一行野郎 200 Blog Not Found (他に忘れられがちなもの以外|意外)に忘れられがちなのが、これ。 ステータス200なのに「その商品はありません」 エンジニア以外の人間が読むと、「ページがなければ404エラー。そんなのあたりまえだろ。」で終わってしまいかねない。 ここでは、「404エラーページを見せろ」ではなく「httpヘッダーで404を返せ」と言っているのがミソだ。 「ステータスコードをいじるのは難しい」といった言い訳をするエンジニアもいるが、それはうそだ。 実はCGIなら、最初の行に"Status: ###"と書き込むだけでWeb Serverがよきに計らってくれる。だから、実はこのことは言語の仕様ですらなく、CGIの仕様だ。以下のShell Scirptは立派なCGIだ。 #!/bin/sh echo "Status: 40
メッセージ。 - 商品がなくても200を返そう。そのかわりに……
[[http://neta.ywcafe.net/000552.html ステータス200なのに「その商品はありません」]] 「商品がないときは404を返そう」という指摘。それは違うんじゃないの？とコメントを書きこんだつもりが（すぐには？）反映されなくて、手元にテキストも残ってなくて不安なのでここにメモ。 「商品がない」のと「ページがない」のは違う。たとえばWikiで、存在しないページにアクセスすると、200と編集画面が返ってくる。ここで404と編集画面を返すとおかしくなる。404と「Not Found」もだめ（まぁ議論の余地がありそうだけど）。HTTPのレイヤーでページがないのと、Wikiのレイヤーでページがないのは違うからだ。 これと同様に、Webアプリケーションのレイヤーで「商品がない」のとHTTPレイヤーで「ページがない」のは違う。たしかにこれは、システムの仕組みが分からない人には
ステータス200なのに「その商品はありません」
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Accident Lawyers Anti Wrinkle Creams fashion trends Top Smart Phones Parental Control Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
Hypertext Transfer Protocol -- HTTP/1.1
Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June 1999 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvem
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC7231のリファラに関するメモ
RequestBin — A modern request bin to collect, inspect and debug HTTP requests and webhooks - Pipedream
ライブドアブログ｜無料で豊富な機能が充実
http://rocketeer.dip.jp/secProg/HttpSecurity001.pdf
POST 後の振る舞い - まちゅダイアリー (2006-02-23)
http://www.gigazine.net/News/html/lg/001057.htm