サイキョウライン » ネットワーク

URIのスキームを省略すると。

yoshuki — Tue, 12 Jul 2011 14:42:42 +0000

http:は省略すれば空気読む – komagata

RFC 2396にちゃんと書いてあるらしい。

シラナカッタ！

ということで読んでみました。

5.2. Resolving Relative References to Absolute Form

のところ、

3) If the scheme component is defined, indicating that the reference starts with a scheme name, then the reference is interpreted as an absolute URI and we are done. Otherwise, the reference URI’s scheme is inherited from the base URI’s scheme component.

ここのことかー！
いやー、ちゃんと「ここで決められてる」って分かるのは気持ちがいいですね。

HTTPステータスコードの定義。

yoshuki — Wed, 12 Aug 2009 14:59:27 +0000

rfc2068.txt

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached.

冒頭の"HTTP status codes are extensible."の解釈について。
コードの１桁目（クラス）に合ってれば、その後はアプリケーションで定義してしまってもいいものか迷ってます。
ここで定義されている401～415までは、TCP/IPのwell-known portみたいなもので、ここにない416～499までは使っちゃってもいいものなのかと。

なんでこんなこと考えてるかというと、FlexのFileReference#upload()で起こるHTTPStatusEventがレンスポンスのステータスコードしかくれないもんで、アップロードされたファイルをアプリで弾いたりした場合に、（すでにあるステータスコード以上に）詳しいことをクライアントで知る術がないのです。ふつうにformで投げればrjs使ってクライアントに表示などできるのですが、アップロード前にファイルサイズを知りたいという要件があるためにこいつに頼らざるをえない状態。responseHeadersにAIRアイコンが付いてるのがうらめしい。

ステータスコード。

yoshuki — Wed, 13 Aug 2008 16:03:57 +0000

HTTP/1.1 200 OK
Status: 200 OK

この２つについて聞かれて、うまく答えられなかったので調べたメモ。

RFC 2616 – Hypertext Transfer Protocol — HTTP/1.1

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

RFC 3875 – The Common Gateway Interface (CGI) Version 1.1

Status = "Status:" status-code SP reason-phrase NL

後者はCGIのヘッダーフィールドなのかー。

急に公開鍵認証が出来なくなったが解決した話。

yoshuki — Thu, 19 Jun 2008 06:17:20 +0000

昨日あたりからDreamHostのsshで公開鍵認証ができなくなって面倒なことになっていたのですが、

COMPROMISED な公開鍵では ssh アクセスが許されない : 僕は発展途上技術者

久々技術的な話題のエントリーを。

こちらのエントリーを見て、もしかしてと思いリモートで自分の鍵を確認したところ、まさにこれでした。

でもローカルに「ssh-vulnkey」というコマンドがなかったのでさらに探してみたら、こんなエントリが。

debianのopensslとopensshに脆弱性 – ksaitoの日記

Debianのセキュリティー勧告によると、DebianとUbuntuなどの派生ディストリビューションでopensslパッケージの不具合によりopensshのssh-keygenで生成した鍵の作り直しが必要になるようです。

1ヶ月前の話かー。ドリホもこれに対応したところだったのかもしれない。

パーミッションやらファイル名やらをしつこく見直してもわからなくてあきらめかけていたところだったので、助かりました。

HTTPレスポンスにゴミが混じる。

yoshuki — Wed, 31 Jan 2007 16:18:37 +0000

と思っていたら、HTTP/1.1の仕様だった。

いしなお! – Amazon WebサービスにHTTP/1.1でアクセスするとゴミが出る

Transfer-Encoding: chunkedだからか！　これで正常なのね。っつーか、HTTP/1.1で送るならば受信側がちゃんと対応しないといけないのね。HTTP/1.1のRFCちゃんと読んでおこう。

くわぁー。こちらを過去に読んだ記憶がある。なんてこった。

あと、HTTP/1.1だとConnection: closeしないとサーバがすぐにコネクションを切ってくれないってのも忘れててわりとハマるんだよねー。おれだけかもしれないけど。

ネットワーク（ブロードキャスト）アドレスを計算する。(IPv4)

yoshuki — Fri, 15 Dec 2006 14:55:09 +0000

$ ipcalc 10.0.123.234/255.255.192.0
Address:   10.0.123.234         00001010.00000000.01 111011.11101010
Netmask:   255.255.192.0 = 18   11111111.11111111.11 000000.00000000
Wildcard:  0.0.63.255           00000000.00000000.00 111111.11111111
=>
Network:   10.0.64.0/18         00001010.00000000.01 000000.00000000
HostMin:   10.0.64.1            00001010.00000000.01 000000.00000001
HostMax:   10.0.127.254         00001010.00000000.01 111111.11111110
Broadcast: 10.0.127.255         00001010.00000000.01 111111.11111111
Hosts/Net: 16382                 Class A, Private Internet

こ、こんな便利なコマンドがあったのかーッッ！！

いままでWindowsの電卓使って（たまに紙に手で書いて）計算していたよ！

もう「255.255.192.0」とか半端なサブネットマスクに憤りを感じなくてもいいのか！

勝手にリダイレクトはダメなんだと。

yoshuki — Wed, 01 Nov 2006 15:35:04 +0000

Hypertext Transfer Protocol — HTTP/1.1

the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user

HTTP/1.1でレスポンスコード

301 Moved Permanently
302 Found
307 Temporary Redirect

を受け取ったときにはリダイレクトする前にユーザに確認しないとダメだよというお話。

これでいつ街角でHTTP/1.1のリダイレクトについて質問されても答えられるよママン。

TCP/IPとHTTPとメールプロトコルと・・・。

yoshuki — Thu, 22 Sep 2005 16:35:09 +0000

最近メールプロトコル編を読み終えたので、その他も含めて。

表紙のデザインや、パッと見(イラストやら文字量やら)の印象と反して、このシリーズは内容がしっかりとしている。

TCP/IP編はネットワークってなに？から、TCP/IPの上に乗っかる上位のプロトコルなどについて広く浅く解説されている。まさに入門書という感じ。

HTTP編はバージョン1.0と1.1両方に対して、それぞれのヘッダの意味がひとつひとつ丁寧に解説されている。ブラウザの戻るボタン対策(キャッシュ云々のはなし)もスッキリした解決策を見つけることができた。

その流れはメールプロトコル編でも同じで、この2冊があればでWebブラウザもメーラもTelnetでまかなえるようになる(って、んなこたないか)。

ともあれ、ソケット開いて直にHTTPを話したり、SMTPでメール送信なんてこともできるのはいざというときに役にたつ。リファレンス的に手元に置いておくのもアリ。

そんな場面に遭遇しなくても、とりあえず「インターネットがどうなってるか」を知るには良い本ではないかと思う。

今夜わかるTCP/IP
翔泳社(2004-12-09)

(著)上野宣

新品価格：￥ 2,415
ASIN：4798108197

今夜わかるHTTP
翔泳社(2004-12-09)

(著)上野宣

新品価格：￥ 2,520
ASIN：4798108200

今夜わかるメールプロトコル
翔泳社(2005-06-17)

(著)上野宣

新品価格：￥ 2,625
ASIN：479810941X

XMLのMIMEタイプ

yoshuki — Tue, 26 Jul 2005 16:00:44 +0000

「application/xml」と「text/xml」の違いが気になってしまったので、調べてみました。
で、コレに言及しているのが「RFC 3023」(RFC 2376は3023と差し替えられて廃止になっている)

5ページの真ん中あたりの

Text/xml and application/xml behave differently when the charset parameter is not explicitly specified.

ヘッダでキャラクタセットが指定されていない時の挙動が違うらしい。

「text/xml」は
「8.5 Text/xml with Omitted Charset」
キャラクタセットが指定されていないと「US-ASCII(ISO-8859-1じゃなくて)」と見なされる(ドキュメント内の宣言(encoding)は無視される)。

「application/xml」は
「8.9 Application/xml with Omitted Charset and UTF-16 XML MIME Entity」
BOMがあればUTF-16として、
「8.10 Application/xml with Omitted Charset and UTF-8 Entity」
BOMがなければUTF-8として、
「8.11 Application/xml with Omitted Charset and Internal Encoding Declaration」
BOMがなく、ドキュメント内の宣言(encoding)があれば、それが適用される。

のだそうな。(8.10と8.11って解釈の順番が逆じゃね？)

とりあえず、いずれもキャラクタセットをつけるのは「STRONGLY RECOMMENDED」となっている(3.1と3.2)ので、UTF-8を使ってるなら

Content-type: text/xml; charset="UTF-8"
Content-type: application/xml; charset="UTF-8"

を投げとけばいいか。