RFC 1958: Architectural Principles of the Internet
Network Working Group B. Carpenter, Editor Request for Comments: 1958 IAB Category: Informational June 1996 Architectural Principles of the Internet Status of This Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The Internet and its architecture have grown in evolutionary f
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 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 1982: Serial Number Arithmetic
Network Working Group R. Elz Request for Comments: 1982 University of Melbourne Updates: 1034, 1035 R. Bush Category: Standards Track RGnet, Inc. August 1996 Serial Number Arithmetic 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 "Intern
HTTP/1.1 just got a major update.
The IETF just published several new RFCs that update HTTP/1.1: RFC 7230: Message Syntax and Routing RFC 7231: Semantics and Content RFC 7232: Conditional Requests RFC 7233: Range Request RFC 7234: Caching RFC 7235: Authentication RFC 7236: Authentication Scheme Registrations RFC 7237: Method Registrations RFC 7238: the 308 status code RFC 7239: Forwarded HTTP extension These documents make the ori
WebSocket(RFC 6455)上で使用するプロトコル設計についての備忘録 - kazuhoのメモ置き場
一般論として、全二重の通信プロトコルを実装するにあたっては、いくつか注意すべき点があって、具体的には、到達確認と切断シーケンスについて定めておかないと、送達されたはずのメッセージがロストしていたり、切断タイミングによってエラーが発生*1したりする。 具体例をあげると、たとえばTCP/IPにおいてshutdown(2)を用いずに、いきなりclose(2)を呼んでいると、read(2)やwrite(2)がエラー(ECONNRESET)を返す場合がある。 翻って、WebSocket (RFC6455)の場合はどうなってるか？ だいたい以下のような感じっぽい。 ws.close()が呼び出されるとWebSocketをCLOSING状態に変更し、Closeフレームを送信する ws.onmessageはWebCosketがCLOSING状態にある間も呼ばれるかもしれない*2 相手からCloseフレーム
RFC 3176: InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks
Network Working Group P. Phaal Request for Comments: 3176 S. Panchen Category: Informational N. McKee InMon Corp. September 2001 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyrig
YappoLogs: HTTP::AcceptLanguage - Accept-Language ヘッダを解析して適切な言語を返す君
HTTP::AcceptLanguage - Accept-Language ヘッダを解析して適切な言語を返す君 月曜日の悪魔こと yappo です。 今時のグローバルな社会ではみなさん多言語対応の web アプリを書いているとおもいますが、その時に使う Accept-Language を解析してくれるのを書きました。 HTTP::AcceptLanguage Plack なアプリだったら。 my $lang = HTTP::AcceptLanguage->new($req->header('Accept-Language'))->match(qw/ en fr es ja zh-tw /);ってするだけで、英語フランス語スペイン語日本語台湾語の中からユーザが利用可能な最適な言語を探して返してくれます。 もし適切な言語が無ければ undef を返すので、あなたがおすすめの言語で返しておくと
IPv6アドレスの:で区切られた部分を何て呼べばいいの？ - yuyarinの日記
IPv6アドレスにおいて:(コロン)で区切られる2バイトの部分を何て呼べばいいのだろうか？IPv4アドレスではオクテット(octet)と呼ばれていて、会話の中で「第4オクテットが〜」みたいな使い方をするのだけど、IPv6アドレスで「第3***が〜」みたいな表現をしたい時に何て呼べばいいのだろうか？調べてみた。 紹介するインターネットドラフトではhextetという単語が提案されていて、NANOGでの一定の支持もあり、個人的にも良さげだったのでこれからはhextetって呼んでいこうと思う。 draft-denog-v6ops-addresspartnaming-04 draft-denog-v6ops-addresspartnaming-04で提案されている呼び方は２種類ある。ただしこのドラフトは2011年にExpireしており、RFCにもなっていない。NANOGのMLで投票なども行われて、こ
HTTP/1.1: Connections
part of Hypertext Transfer Protocol -- HTTP/1.1 RFC 2616 Fielding, et al. 8 Connections 8.1 Persistent Connections 8.1.1 Purpose Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often require a client to make multiple requests o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
