メールアドレスの正規表現 - tmtms のメモ
たまにメールアドレスの形式を正規表現で表すのは不可能とかというのを目にするのですが、そんなことはありません。入れ子がなければたいていの文字列の形式は正規表現で表すことができます。 ということで、RFC5321, 5322 からメールアドレスの正規表現を書いてみました。 /\A([0-9a-z!\#$%&'*+\-\/=?^_`{|}~]+(\.[0-9a-z!\#$%&'*+\-\/=?^_`{|}~]+)*|\"([\x20\x21\x23-\x5b\x5d-\x7e]|\\[\x20-\x7e])*\")@[0-9a-z]([0-9a-z-]*[0-9a-z])?(\.[0-9a-z]([0-9a-z-]*[0-9a-z])?)*\z/i ちょっと長いですけど、最近の Ruby だと (?<hoge>) と \g<hoge> を使うことで、同じ正規表現の繰り返しを簡単に書くことができる
Transfer-Encoding: chunked について - 理系学生日記
Tomcat をコンテナとした Servlet のコード上で Content-Length ヘッダを設定していたのですが、なぜか HTTP レスポンスのヘッダには Content-Length が出力されないという事象が確認されました。 これは一体なぜなのだろうと調べていると、当該レスポンスのヘッダに Transfer-Encoding: Chunked が出力されていることに気付きました。 Chunked は HTTP/1.1 で定義されている方式です。RFC 2068 には以下のような記述があり、Chunked と Content-Length を共存させてはいけない (MUST NOT) ことが分かります。) Messages MUST NOT include both a Content-Length header field and the "chunked" transfer
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
