ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont
DKIM ADSP は廃止されています (HISTORIC です) | IIJ Engineers Blog
IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 結論 https://www.rfc-editor.org/rfc/rfc5617.html (HISTORIC) (※1) 新しくドメイン名を登録された方へ DKIM ADSP レコードは、もはや書く必要はありません。 誰も見ていませんし、評価の対象になっていないと考えて差し支えありません。 すでにドメイン名を運用されている方へ DKIM ADSP レコードが書いてあるかは、次のように調べられます。 $ dig _adsp._domainkey.example.jp
HTTPのキャッシュを無効化するAPIの標準化する提案仕様 - ASnoKaze blog
CDNはキャッシュをパージする機能をよく有しています。そのキャッシュの無効化(もしくはパージ)を要求するためのAPIを標準化するための『An HTTP Cache Invalidation API』という提案仕様がIETFに提出されています。 この 提案仕様は、HTTP界隈では著名な Mark Nottingham氏による提案です。まだ最初の提案であり、来月あるIETF会合で紹介があるものと思われる。 An HTTP Cache Invalidation API この仕様では、次のペイロードを含むPOSTを送ることで、キャッシュの無効化を要求できる { "type": "uri", "selectors": [ "https://example.com/foo/bar", "https://example.com/foo/bar/baz" ], "purge": true } type:
RFCの読み方
こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC（Request For Comments）が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF（Internet Engineering Task Force）というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments（コメント募集）という名前にしていたようです
HPKE とは何か | blog.jxck.io
Intro HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。 RFC 9180: Hybrid Public Key Encryption https://www.rfc-editor.org/rfc/rfc9180.html HPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。 この仕様は、多くのユースケースが想定されており、 RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。 本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多く
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
IETFによるHTTP/3の標準化プロセスが完了、「RFC 9114」に
IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ＝リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに
あなたのWebサービスの脆弱性を発見者から教えてもらう方法 - RFC9116が発表されました
先日、RFC9116が発表されました🚀 あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。 この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。 なぜこれが必要だったのか https://securitytxt.org/のSummary(概要)にはこのように書かれています。 Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
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の理解ができることを
QUIC is now RFC 9000
QUIC is now RFC 9000QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient, and more trusted internet. In fact, we believe so much in the promis
「RFC違反」アドレスのドコモメール、iOS14で送信不可に
NTTドコモは、国際標準「RFC」に準拠していないアドレスのドコモメール（@docomo.ne.jp）が、iOS14以降のメールアプリで送信できなくなる事象を確認していると発表した。対象のユーザーには、メールアドレスを変更するか、プロファイル更新するよう案内している。 iOS14以降で、アドレス内に2連続のドット（..）が含まれていたり、アットマーク前にドット（.@）が含まれているアドレスを利用している場合に、メールが送信できなくなることを確認したという。 RFCは、インターネットの標準化団体IETF（The Internet Engineering Task Force）が発行している、技術仕様をまとめた文書。2009年ごろまでに作られた日本のキャリアメールのアドレスの一部はRFCに準拠していないと以前から指摘されており、トラブルの元になると批判されていた。
Mastodon OStatus API の叩き方
mastodon-ostatus.md Mastodon が他のインスタンスと情報交換をする OStatus API の使い方。使ってるだけのユーザは知る必要がない裏側の話。 host-meta Mastodon インスタンスに対して、RFC6415 が規定する /.well-known/host-meta というパスを要求すると以下の XML が返ってくる. <?xml version="1.0"?> <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0"> <Link rel="lrdd" type="application/xrd+xml" template="https://[MASTODON_HOST]/.well-known/webfinger?resource={uri}"/> </XRD> "lrdd" は Link-b
RFC1034読書会に行ってきたよ - infragirl’s blog
2017/03/01 追記 近日中にセルフ赤ペンが入ります。 2017/03/04 追記 ただいま、セルフ赤ペン中です。 2017/03/08 追記 セルフ赤ペンしました。 おはこんばんにちは。なつよです。 プライベートやお仕事が立て込む日々です。 インフラガール活動の時間、もうちょっと増やしたい・・・(ﾉД`) 今回は、先日行ってきたRFC1034読書会について書こうと思います。 RFC1034とは？ とってもざっくり言うと、DNSに関するRFCです。 私は、TwitterでDNSDNS言ってたら、「まずRFC1034を読むことだ、話はそれからだ」と言われて知りました。 RFC1034読書会とは？ 浸透言うな先生こと鈴木先生(@tss_ontap_o)主催の会です。 atnd.org なんで参加しようと思ったの？ RFC1034,日本語訳を読んでみたのですがまったくわからんかったのです。
メールを受け取らないドメイン名に
example.comゾーンには次の内容で登録されているものとします。 example.com. 86400 IN A 192.0.2.80 送信側メールサーバは次のような順番で処理を行います。 宛先メールアドレス"foo@example.com"のドメイン名"example.com"に対するMXレコードを問い合わせる。 "example.com"に対する回答として0個のMXレコードを受け取る。（MXレコードが登録されていないため。なお、"example.com"そのものは存在するため、回答のステータスとしては"NOERROR"である。） "example.com"に対するAレコードを問い合わせる。（MXレコードが存在しないときには、Aレコードにフォールバックするため） "example.com"に対する回答としてIPアドレス"192.0.2.80"を値とするAレコードを受け取る。 IPア
Web 関連仕様 日本語訳
このページは、 Web プラットフォーム関連の様々な仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。 これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、
私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
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
RFC 7540 日本語訳
この文書は「RFC7540」の日本語訳です。 原文の最新版は、この日本語訳が参照した版から更新されている可能性があります。 この日本語訳は参考情報であり、正式な文書ではないことにも注意してください。また、翻訳において生じた誤りが含まれる可能性があるため、必ず原文もあわせて参照することを推奨します。 公開日: 2015-05-17 更新日: 2015-07-22 翻訳者: Moto Ishizawa <[email protected]> 翻訳協力: Shigeki Ohtsu, Kazu Yamamoto 概要 この仕様は、HTTP バージョン2 (HTTP/2) と呼ばれる、最適化された Hypertext Transfer Protocol (HTTP) のセマンティクス表現について説明します。HTTP/2 は、ヘッダーフィールドの圧縮を導入し、同一接続上での複数同時通信の実現により、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dkim.jp