とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
ネットワーク WG Request for Comments： 5246 廃止： 3268, 4346, 4366 更新： 4492 分類： Standards Track このメモの位置づけ 本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。 要旨 本書は、TLS（Transport Layer Security）プロトコルのバージョン 1.2 を規定する。TLS プロトコルは、インターネット上の通信セキュリティを提供する。このプロトコルは、クライアント／サーバアプリケーションが盗聴
当ブログをご愛読頂いている方であれば、当然ご存知ないことと思いますが、俺は DNS が大好きです。 とは言っても、DNS サーバーの構築とか運用に詳しいわけでも、攻撃に対抗する方法を知っているわけでもありません。 やったことがあるのは、せいぜい、レンタル DNS サーバーでゾーン定義ファイルを書いて遊ぶくらいのものです。 昨今は、DNSSEC で遊びたいのですが、そのための環境が無く、悲しみに暮れています。 閑話休題。 タイトルの 2/3 のジレンマというのは、DNS の運用において成立させたい、とある 3 つの性質のうち、同時に成立できるのは 2 つまでで、3 つ全部を成り立たせるのは不可能だ、ということを指しています。 その 3 つの性質というのは、 Zone Apex によるアクセス DNS サーバーのアウトソーシング 変動する IP アドレス です。 こういうの、何て言うんでしょう
トップページ - 翻訳ドキュメント - RFC 1034 原文：ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt 原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。 サイト内関連リンク：RFC 1035 DNS 実装と仕様 Network Working Group Request for Comments: 1034 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - CONCEPTS AND FACILITIES ドメイン名- 概念と機能 1. STATUS OF THIS MEMO 1. この文書の位置付け This RFC is an introduction to t
Network Working Group R. Rivest Request for Comments: 1321 MIT Laboratory for Computer Science and RSA Data Security, Inc. April 1992 The MD5 Message-Digest Algorithm Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Acknowlegements We would like to thank Don Coppersmith, Burt Kaliski, Ra
モバイルでもDNSラウンドロビンはちゃんと動作しますか？ PCであれば、だいたいのブラウザが対応していると聞きますが、モバイルはどうなんでしょうか？ A、B、Cというサーバをラウンドロビンで動かした時に、Bが死んだとします。 その場合、PCはBに行かなくなると思いますが、携帯の場合はどうなんでしょうか？ 携帯はキャリアのプロキシ？か何かを通っていそうなので、ちゃんと動くのかが気になります。 また、ラウンドロビンの弱点は何ですか？ 今のところ気づいているのは、単に振り分けるだけだから1台に負荷が集中するかもしれないことくらいしかないです。 上の質問を見て、「あれっ、ラウンドロビンって、ブラウザのようなアプリケーションサイドで対応するものだっけ？ gethostbyname 辺りで勝手にやっていて、アプリ側は渡された IP で繋ぐだけでは？」と思っていたら、それは、もう古い話らしい。 0000
本文書は RFC1918 を日本語に訳したものであり、原文と語彙あるいは解釈の 相違が生じる場合は原文を正しいものとする。訳者および日本語訳に関わった 全ての関係者は、本文書によって読者が被り得る如何なる損害の責任をも 負わない。 上田 健 ken@sphere.ad.jp (株)NTT PC コミュニケーションズ ------------------------------------------------------------------------ Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best Current Practice D. Ka
この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。 翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。 翻訳についてのお問合せ先：（SSL対応フォーム） （非SSL対応フォーム） 翻訳者一覧 株式会社リコー 山本陽平 日野原寛 高桑寿一 中川勝樹 沖田邦夫 井上浩一 兵清弘 リコーソフトウエア株式会社 福田朋紀 更新履歴 2008-01-07 日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正 2007-12-06 9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正 2007-11-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正 2007-11-0
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。（多用されているかはともかく）Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
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
UUID がどういうものであるか，とか UUID の表現形については省略します。 UUID - Wikipedia が参考になるかと。 UUID の仕様として RFC 4122 を参照しました*1。なのでより細かいことについては原文を参照してください。策定されるまでにいろいろ経緯があるのですが，そのへんは http://www.rfcnews.jp/archives/2005/07/rfc_4122uuidurn.html に譲ります。 UUID の構造 UUID の内部構造をおおまかに表すと以下のようになります。 variant 2 bit (3 bit) version 4 bit time 60 bit clock_seq 14 bit (13 bit) node 48 bit 実際には variant フィールドは clock_seq フィールドのオクテットの中に埋め込まれています
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
