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アイコンが付いてるのがうらめしい。
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のヘッダーフィールドなのかー。
昨日あたりからDreamHostのsshで公開鍵認証ができなくなって面倒なことになっていたのですが、
COMPROMISED な公開鍵では ssh アクセスが許されない : 僕は発展途上技術者
久々技術的な話題のエントリーを。
こちらのエントリーを見て、もしかしてと思いリモートで自分の鍵を確認したところ、まさにこれでした。
でもローカルに「ssh-vulnkey」というコマンドがなかったのでさらに探してみたら、こんなエントリが。
debianのopensslとopensshに脆弱性 – ksaitoの日記
Debianのセキュリティー勧告によると、DebianとUbuntuなどの派生ディストリビューションでopensslパッケージの不具合によりopensshのssh-keygenで生成した鍵の作り直しが必要になるようです。
1ヶ月前の話かー。ドリホもこれに対応したところだったのかもしれない。
パーミッションやらファイル名やらをしつこく見直してもわからなくてあきらめかけていたところだったので、助かりました。
と思っていたら、HTTP/1.1の仕様だった。
いしなお! – Amazon WebサービスにHTTP/1.1でアクセスするとゴミが出る
Transfer-Encoding: chunkedだからか！ これで正常なのね。っつーか、HTTP/1.1で送るならば受信側がちゃんと対応しないといけないのね。HTTP/1.1のRFCちゃんと読んでおこう。
くわぁー。こちらを過去に読んだ記憶がある。なんてこった。
あと、HTTP/1.1だとConnection: closeしないとサーバがすぐにコネクションを切ってくれないってのも忘れててわりとハマるんだよねー。おれだけかもしれないけど。
$ 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」とか半端なサブネットマスクに憤りを感じなくてもいいのか！
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編はネットワークってなに？から、TCP/IPの上に乗っかる上位のプロトコルなどについて広く浅く解説されている。まさに入門書という感じ。
HTTP編はバージョン1.0と1.1両方に対して、それぞれのヘッダの意味がひとつひとつ丁寧に解説されている。ブラウザの戻るボタン対策(キャッシュ云々のはなし)もスッキリした解決策を見つけることができた。
その流れはメールプロトコル編でも同じで、この2冊があればでWebブラウザもメーラもTelnetでまかなえるようになる(って、んなこたないか)。
ともあれ、ソケット開いて直にHTTPを話したり、SMTPでメール送信なんてこともできるのはいざというときに役にたつ。リファレンス的に手元に置いておくのもアリ。
そんな場面に遭遇しなくても、とりあえず「インターネットがどうなってるか」を知るには良い本ではないかと思う。
「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"
を投げとけばいいか。
