逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
最速攻略！ Reactの `use` RFC
皆さんこんにちは。最近のReact界隈で話題になっているのは次のRFCです。 そこで、この記事ではさっそくRFCを理解することを目指します。 ただし、このRFCはSuspenseに深く関わるものです。SuspenseはReact 18でもう正式リリースされていますから、この記事ではSuspenseは前提知識とします。もしまだSuspenseをよく知らないのであれば、ぜひ次の記事で学習してください。 また、RFCはあくまでReactの新機能のアイデアを公開するものであり、これが必ず実装されるとは限らない点にご注意ください。例えば、過去にはuseEventというRFCが注目を集めていましたが、意見が集まった結果としてそのRFCは実装されずにクローズされました（RFCが無駄だったというわけではなく、再度検討してよりアイデアがブラッシュアップされることになります）。 新しい use API このR
RFC 9293: Transmission Control Protocol (TCP)
Stream: Internet Engineering Task Force (IETF) STD: 7 RFC: 9293 Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 6691 Updates: 1011, 1122, 5961 Category: Standards Track Published: August 2022 ISSN: 2070-1721 Author: RFC 9293 Transmission Control Protocol (TCP) Abstract This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protoco
「バグを意図的にバグのまま残す」という選択肢がある
はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。本記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++
最近のC言語と、次期C標準(C23)
C言語といえば古い言語なイメージですが、その重要性はまだまだ落ちていません（多分）。重要な言語だからこそ、今もひっそりと進化を続けています。この記事では、そんなC言語の最近の動向を紹介します。 まずはC言語の前世紀の標準であるC99、現行の標準であるC11/C17を振り返り、その後に未来の標準であるC23に触れます。 C99 C99では色々追加されました。ここでは一部のみの紹介とします。 _Bool _Complex C++の std::complex とメモリ上での互換性がある（C++11以降）。 可変長配列（VLA） 可変長引数マクロ 浮動小数点数の強化 十六進表記 筆者による関連記事：浮動小数点数の16進表記 fma 筆者による関連記事：FMA (fused multiply-add) の話 #pragma STDC FENV_ACCESS, #pragma STDC CX_LIMI
次期C標準 (C23) の内容が固まったらしい
C23については最近のC言語と、次期C標準(C23)でも軽く紹介しました。 今回、C23入りする内容が大体固まったようなので改めて紹介します。 この記事を書いている時点での最新の公開されたWorking Draftは N2912 N3047 N3054 N3096です。ただし、C2y向けの最初のドラフトN3220もあり、そちらの方が実際の内容に近いかもしれません。 内容については会議参加者の投稿も参考にしています： https://twitter.com/rcs/status/1550526425211584512 C23 now finalized! : C_Programming というわけで、C23に入る主な機能はこちらです： C23に入る主な機能 POSIXの機能の取り込み: strdup, strndup, memccpy, gmtime_r, localtime_r C++の機
W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」（分散型識別子）の仕様が勧告に到達
W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」（分散型識別子）の仕様が勧告に到達 World Wide Web Consortium (W3C)は、「Decentralized Identifiers (DIDs) 」（分散型識別子）バージョン1.0（以下、W3C DID）の仕様が勧告に到達したと発表しました。 W3C press release: "Decentralized Identifiers (DIDs) v1.0 becomes a W3C Recommendation" "This new type of verifiable identifier... will enable both individuals and organizations to take greater control of their onl
WebAssembly Specifications
To support the embedding of WebAssembly into different environments, its specification is split into layers that are specified in separate documents. Core specification Defines the semantics of WebAssembly modules independent from a concrete embedding. The WebAssembly core is specified in a single document: WebAssembly: defines the structure of WebAssembly modules, their instruction set, and their
Dangerous Labels in DNS and E-mail
Workgroup: intarea Internet-Draft: draft-dkg-intarea-dangerous-labels-01 Published: 21 May 2022 Intended Status: Informational Expires: 22 November 2022 Author: Dangerous Labels in DNS and E-mail Abstract This document establishes registries that list known security-sensitive labels in the DNS and in e-mail contexts.¶ It provides references and brief explanations about the risks associated with ea
The JavaScript Specification has a New License – Mozilla Hacks - the Web developer blog
Ecma International recently approved the 2022 standard of ECMAScript. There is something new in this edition that hasn’t been part of prior editions, but this isn’t a new programming feature. In March of this year, Ecma International accepted a proposal led by Mozilla for a new alternative license. On June 22nd, the first requests to adopt this license were granted to TC39 and applied to the follo
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 の一覧を取得している間に、先行し
RFC 8297: An HTTP Status Code for Indicating Hints
Internet Engineering Task Force (IETF) K. Oku Request for Comments: 8297 Fastly Category: Experimental December 2017 ISSN: 2070-1721 An HTTP Status Code for Indicating Hints Abstract This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. Status of This Memo This document is not an Internet Stan
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
Stream: Internet Engineering Task Force (IETF) RFC: 9116 Category: Informational Published: April 2022 ISSN: 2070-1721 Authors: RFC 9116 A File Format to Aid in Security Vulnerability Disclosure Abstract When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsa
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が
HTTPで再開可能なアップロードを可能にする提案仕様 - ASnoKaze blog
HTTPでファイルをアップロードする時、ネットワークの寸断などによりアップロードが中途半端に終わってしまうことがあります。アップロードが途中まで成功したとしても、一度切断するとそこから再開する方法は標準化されていません。 (PUTリクエスト + Rangeヘッダによる再開をサポートしているシステムもありますが標準化されてはいません。 参考URL) そこで、再開可能なアップロードの仕組みを定義した「Resumable Uploads Protocol」という仕様がIETFに提出されています。この仕様は、Transloadit Ltd, Apple Inc, Cloudflare などの方々の共著になっています。 Resumable Uploads Protocol の概要 「Resumable Uploads Protocol」は、一度中断しても再開可能なアップロード方式を定義しています。
JavaScript の MIME タイプが `text/javascript` に統一されようとしている
現在、 JavaScript の MIME タイプは2006年4月に公開された RFC 4329(www.rfc-editor.org) にて text/javascript (OBSOLETE) application/javascript (COMMON) text/ecmascript (OBSOLETE) application/ecmascript (COMMON) の4つが定義されています。 この RFC 4329 では text/* の2つは OBSOLETE 扱いな一方で、 JavaScript を呼び出す HTML の仕様では HTML5 以降、 <script> 要素の type 属性を省略することが推奨 されたうえで、省略時の値は text/javascript である とされました。 このように RFC 側と HTML 側で矛盾が生じる事態が長い間続いています。 実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC: First class support for promises and async/await by acdlite · Pull Request #229 · reactjs/rfcs
「418 I'm a teapot」が永久欠番（？）に ～25年前の発行されたジョークRFCの後始末／【やじうまの杜】
An HTTP Status Code for Indicating Hints
RFC8297