HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
RFC 7763: The text/markdown Media Type
Internet Engineering Task Force (IETF) S. Leonard Request for Comments: 7763 Penango, Inc. Category: Informational March 2016 ISSN: 2070-1721 The text/markdown Media Type Abstract This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Status of This Memo This do
RFC 6530: Overview and Framework for Internationalized Email
Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 6530 Y. Ko Obsoletes: 4952, 5504, 5825 February 2012 Category: Standards Track ISSN: 2070-1721 Overview and Framework for Internationalized Email Abstract Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in
How can I validate an email address using a regular expression?
The fully RFC 822 compliant regex is inefficient and obscure because of its length. Fortunately, RFC 822 was superseded twice and the current specification for email addresses is RFC 5322. RFC 5322 leads to a regex that can be understood if studied for a few minutes and is efficient enough for actual use. One RFC 5322 compliant regex can be found at the top of the page at http://emailregex.com/ bu
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
RFC 6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
Internet Engineering Task Force (IETF) P. Saint-Andre Request for Comments: 6648 Cisco Systems, Inc. BCP: 178 D. Crocker Category: Best Current Practice Brandenburg InternetWorking ISSN: 2070-1721 M. Nottingham Rackspace June 2012 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols Abstract Historically, designers and implementers of application protocols have often disting
OAuth2.0 RFC6749へ対応します - ニュース
カテゴリー別ニュース (743)mixi Connect (92)mixi OpenID (4)mixi Platform 共通 (69)mixiアプリ (560)mixiページアプリ (13)障害情報 (207)mixi Connect (16)mixi OpenID (1)mixi Platform 共通 (42)mixiアプリ (134)mixiページアプリ (8)重要なお知らせ (36) mixi Graph APIにアクセスするために必要な認証認可として、OAuth2.0 Draft10に準拠した認証認可手順をご提供しております。 2012/10/24(水)にOAuth2.0 RFC6749へ対応しますことをお知らせいたします。 ＜準拠仕様：現在＞ [The OAuth 2.0 Protocol draft-ietf-oauth-v2-10] http://openid-foun
Randomness Requirements for Security
ネットワーク WG Request for Comments： 4086 BCP： 106 廃止： 1750 分類： ベストカレントプラクティス D. Eastlake 3世 Motorola Laboratories J. Schiller MIT S. Crocker 2005年 6月 English セキュリティのための乱雑性についての要件 (Randomness Requirements for Security) このメモの位置づけ この文書は、インターネットの「現時点における最善の実践（ベストカレントプラクティス）」を示すものであり、改善するために議論と示唆を求めるものです。このメモの配布に制限はありません。 著作権表記 Copyright (C) The Internet Society (2005). 要旨 セキュリティシステムは、強い暗号アルゴリズムに基づくようになってお
RFC 6265 — HTTP State Management Mechanism （日本語訳）
RFC6265 — HTTP State Management Mechanism （クッキー処理仕様）日本語訳 このページは IETF による, 2011 年 12 月発行 PROPOSED STANDARD RFC 6265 （HTML 版） "HTTP State Management Mechanism" を日本語に翻訳したものです。 この翻訳の正確性は保証されません。 この日本語版は公式のものではありません。 本文ダブルクリックで当該箇所の原文を表示（左下隅ボタンで原文の全表示切替）。 定義用語クリックで参照元へのリンクを表示。 （ CSS や DOM の対応が古いブラウザでは、これらの機能が一部働かないかもしれません。 HTML5 の section タグなども利用されています。） 更新：2012-09-20 （ 公開：2012-07-17, 更新日時点の URL ） 誤訳その
RFC 5789: PATCH Method for HTTP
Internet Engineering Task Force (IETF) L. Dusseault Request for Comments: 5789 Linden Lab Category: Standards Track J. Snell ISSN: 2070-1721 March 2010 PATCH Method for HTTP Abstract Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal
セキュリティ関連 RFC：IPA 独立行政法人 情報処理推進機構
IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向
RFC 5849: The OAuth 1.0 Protocol
Internet Engineering Task Force (IETF) E. Hammer-Lahav, Ed. Request for Comments: 5849 April 2010 Category: Informational ISSN: 2070-1721 The OAuth 1.0 Protocol Abstract OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server r
RFC 3629: UTF-8, a transformation format of ISO 10646
Network Working Group F. Yergeau Request for Comments: 3629 Alis Technologies STD: 63 November 2003 Obsoletes: 2279 Category: Standards Track UTF-8, a transformation format of ISO 10646 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Int
CSVファイルの一般的書式 (RFC4180 日本語訳) - アルプス登山の玄関口・笠井家
2005年10月に公開された、RFC4180「Common Format and MIME Type for Comma-Separated Values (CSV) Files (CSVファイルの一般的書式、およびMIMEタイプ) 」の日本語訳です。謝辞と文献の箇所は原文のままです。 データ交換において頻繁に使われるCSV形式ですが、ベンダの独自仕様が乱立しているのが実情です。 本RFCは、遅まきながら出てきた、最初にして唯一の、「公式(?)」な仕様です。もっとも、区分 (Category) がInformationalのRFCなので、「標準」ではありませんが… 原文は、http://www.ietf.org/rfc/rfc4180.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フ
studyinghttp.net -
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.
RFC 3986 - Uniform Resource Identifier (URI): 一般的構文
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.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
PHP: rfc:uconverter
https://www.rfc-editor.org/rfc/rfc6265.txt