Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
HTTP（ RFC7230 〜 RFC7235 ）共通ページ
この~pageでは、 ~IETFによる `Hypertext Transfer Protocol（ HTTP ）＠~HTTPWG/$ の 2014年に公表された~versionを成す，次に挙げる仕様に共通な内容を（日本語訳にあたり）集約する ⇒＃ `RFC7230＠~7230$, `RFC7231＠~7231$, `RFC7232＠~7232$, `RFC7233＠~7233$, `RFC7234＠~7234$, `RFC7235＠~7235$ これらは、 今や，2022年 6 月に公表された中核~HTTP仕様（ RFC9110, RFC9111, RFC9112 ）により廃用にされた。 それらの日本語訳は、 `~HTTP日本語訳 共通~page＠~HTTPcommon$にある。 ~HTTPに関係する各種 RFC の（網羅的でない）一覧, および ~HTTP全般に共通な内容（構文の表記法な
JOSE（JavaScriptオブジェクトへの署名と暗号化）は、絶対に避けるべき悪い標準規格である | POSTD
注： 本稿は元はJSON Web Tokens（JWT）について書いたものですが、JWTはJavascript Object Signing and Encryption（JOSE）のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption（JOSE）を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption（JWE）、JSON Web Signatures（JWS）のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能
ウェブ関連仕様 日本語訳（ www.hcn.zaq.ne.jp/___/WEB/ ）
このページ は、このページの URL パス下にある，ウェブプラットフォーム関連の仕様の日本語訳の一覧と，各ページに共通する事項についての説明です。 これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、日本語訳は公式のものではありません。 一部の仕様（特に WHATWG によるもの）は日々更新され続けているので、日本語訳には最新版ではないものもあります。 また、原文の更新に伴う，ページ更新の際に見落としがあるかもしれません（更新部分の日本語訳への複製／統合段階など）。 その完全性は保証されませんが、不定期に検証されてはいます。 Jacascript ／ CSS ／ DOM の対応が古いブラウザでは、表示が崩れたり，一部の機能が働かないかもしれません（特に IE 6〜8 はほとんど考慮されていません）。 例えば目次など，一部ページ内容はスクリプトで自動生成されていま
あたらしいHTTPの話をしよう
あたらしいHTTP/1.1、RFC7230-7239のざっくりしたまとめ http://blog.hmm.jp/entry/new-http1.1-rfcs
RFC 6819: OAuth 2.0 Threat Model and Security Considerations
Internet Engineering Task Force (IETF) T. Lodderstedt, Ed. Request for Comments: 6819 Deutsche Telekom AG Category: Informational M. McGloin ISSN: 2070-1721 IBM P. Hunt Oracle Corporation January 2013 OAuth 2.0 Threat Model and Security Considerations Abstract This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive thr
RFC 6570: URI Template
Internet Engineering Task Force (IETF) J. Gregorio Request for Comments: 6570 Google Category: Standards Track R. Fielding ISSN: 2070-1721 Adobe M. Hadley MITRE M. Nottingham Rackspace D. Orchard Salesforce.com March 2012 URI Template Abstract A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification def
RFC2616: ハイパーテキスト転送プロトコル -- HTTP/1.1
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
OpenID Foundation Japan - 翻訳・教育 Working Group
OpenID Foundation Japan 翻訳・教育 Working Group は、OpenID Foundation Japan 参加メンバーを中心に、有志により運営されています。現在は主に OpenID & OAuth 関連仕様書の翻訳活動を行っています。 翻訳ドキュメント一覧 OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。 OpenID Attribute Exchange は、エンドポイント間で属性情報を交換するための OpenID の拡張仕様である。ユーザーの属性情報を更新または取得するためのメッセージを提供する。 Open
RFC 6455 - The WebSocket Protocol（日本語訳）
RFC6455 - The WebSocket Protocol 日本語訳 この文書は、 IETF による, 2011 年 12 月付け発行 PROPOSED STANDARD RFC 6455 "The WebSocket Protocol" （HTML 版） を日本語に翻訳したものです。 この翻訳には翻訳上の誤りがあるかもしれませんし、正確性は保証されません。 この仕様の公式な文書は英語版であり、この日本語版は公式のものではありません。 最終更新日時点のこのページの URL ： http://www.hcn.zaq.ne.jp/___/WEB/RFC6455-ja.html CSS や DOM の対応が古いブラウザでは、閲覧に不具合が生じたり, 一部の切替機能（ウィンドウ左下隅：原文表示＝アクセスキー Z, 原語表示＝アクセスキー X ）が働かないかもしれません（ HTML5 から導入
JPRS DNS 関連技術情報
このページは DNS に関連する技術情報を提供するページです。 [ 最終更新：2024年08月05日 更新履歴はこちら] [ RSS ] ■ トピックス L4 グルーレコードについて改めて考える ～ランチのおともにDNS～(「Internet Week 2023」での発表資料[PDF]) DNSを用いたドメイン名の管理権限確認を使用する際の注意点(IETF 116 Host Equipment Demosでの配布資料[PDF]) Important Notes of Using Domain Name Ownership / Control Verification by DNS (Distributed on IETF 116 Host Equipment Demos[PDF]) L6 DNSの弱点を振り返り、今後の針路について考える ～ランチのおともにDNS～(「Internet We
ＤＮＳのＲＦＣ
ＤＮＳのＲＦＣ 基本的なＤＮＳの仕様(Standards) RFC 1034「ドメイン名－概念と機能」（日本語訳） RFC 1035「ドメイン名－実装と仕様書」（日本語訳） ＤＮＳといえば、この２つが標準になります。 ＤＮＳができる前のインターネットでは、ネットワーク情報センター(NIC)で管理していたHOST.TXTファイルに、 ホスト名とＩＰアドレスの対応を書いて、これを各ホストに配っていました。 このやり方は配布に時間がかかるなど、いろいろ問題がありました。 この解決のため、様々な方法の提案と実装されました （RFC 799, RFC 810, RFC 811, RFC 819, RFC 830, RFC 882, RFC 883, RFC 953など）。 最終的に決まったドメインネームシステムの内容を記述したのがこの２つのＤＮＳ仕様書になります。 ＤＮＳの考え方、ＤＮＳでよく使われ
IETFとRFC - JPNIC
IETFとは インターネット技術の国際標準を議論策定しているIETFは、 コンピュータサイエンスの技術者達が、 自身の実験網を構築運用するために共通の技術仕様を策定および共有するために草の根的な議論を行うグループから発展したものです。 当初、10名以下のグループからスタートしたグループは、2000年当時でも、 年3回のIETF会合に2000名以上の参加者があり、 24時間絶え間なく電子メールによる議論が行われていました。 IETFにおける標準化のプロセスは、 ITU-TやISOにおける標準化のプロセスとは大きく異なっています。 ここでは、IETFの概要、歴史、組織構造、標準化のプロセス、 およびIETFの文化についての解説を行います。 IETFとは～はじめに～ IETFの背景と歴史 IETFの組織構造 IETFにおける標準化プロセス IETF会合の様相 IETFとは～むすび～ IETF会議
セキュリティ関連 RFC：IPA 独立行政法人 情報処理推進機構
IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向
Request for Comments - Wikipedia
ウィキペディアの記事編集での Request for Comments への自動外部リンク機能については「Help:マジックリンク#RFC」をご覧ください。 Request for Comments（リクエスト フォー コメンツ、略称：RFC）はIETF（Internet Engineering Task Force）による技術仕様の保存、公開形式である。内容には特に制限はないが、プロトコルやファイルフォーマットが主に扱われる。RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。全てのRFCはインターネット上で公開されており、誰でも閲覧することができる。 なお、IETF以外の組織・コミュニティにおいても、同様の目的の文書群をRFCと呼称する事例が存在する。 PHP: PHP:
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
Network Working Group T. Berners-Lee Request for Comments: 3986 W3C/MIT STD: 66 R. Fielding Updates: 1738 Day Software Obsoletes: 2732, 2396, 1808 L. Masinter Category: Standards Track Adobe Systems January 2005 Uniform Resource Identifier (URI): Generic Syntax Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
＠IT：DNSの拡張仕様、SRVレコードとENUM（1/2）
IETF RFC2119 Requirement Levels
DNS Summer Days 2012 DNSのRFCの歩き方 - 株式会社ハートビーツ 滝澤隆史 日本Unboundユーザー会
http://au.net/ietf/rfc/PDF/