読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(akashic report) akka-httpはクライアントが送ってきたContent-Typeを改竄する

akashic-storageは, finchを捨てて, akka-httpに移住することとなった.

この決断はたぶん正しい. 実際にakka-httpで書いた方が, コードはシンプルになっている. ただし, 一点だけ気に食わないことがある. これが実際に, S3の署名実装において仇となっている. akka-httpには, ぜひ, クライアントが送ってきた生のContent-Typeにもアクセス出来るようになってほしい.

私が今観測しているのは, クライアントが, Content-Type: text/plainを送ってきた場合に, akka-http内でHttpEntity.contentTypeをとると, これがtext/plain; charset=UTF-8になっているということだ. これはたぶん, サーバ実装を行う上ではフルセットの情報があった方が良いからという理由で, パーシングのあと正規化のような処理が加わってるのだと思うが, 余計なことをしてほしくない.

私のアイデアは, headersにRawHeaderとして, 改竄前のContent-Typeも残すということである. とりあえずやってみてもいいかな. こういうのを残すメモリすら節約したいです派には, keep-raw-content-typeという設定で避けても良い. パーシングの時点では存在した情報のはずだから, アプリケーション独自ヘッダ(X_AMZ_xxxなど)と同様に扱ってあげれば良いだけに思う. おそらく, Content-Typeだからという理由で避けられてるコードがあるはずだ.

S3署名では, Content-Typeの文字列を, クライアントが送ったそのままの状態で使う必要がある. だから, 認証に失敗している.

WorkAroundは, Stream(contentType.valueを使った認証, mediaType.valueを使った認証)のうちどちらかが成功すれば成功とみなすというものだが, 嫌すぎる・・・.

ちなみにakkaのGitter Channelでは無視されている. やはりfinchに戻るべきか.

(追記)

少し調査をしてみた. parseEntityに入ってきた時点ではもうUTF-8が追加されている.