Go language part 3

[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞あぼーん

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

497: 2020/05/16(土)11:46 ID:e+rgeli+(1/20) AAS
1.12 の http/request.go に、でっかい落とし穴が

こいつは、1210 行目で ContextType == "multipart/form-data" の処理が未実装

そして、 Chrome は FormData オブジェクトを XMLHttpRequest で send() すると問題のマルチパートで送りつける

よって、FormData は使えない……

他のブラウザだとどうなんだろ？困るな

499: 2020/05/16(土)12:29 ID:e+rgeli+(2/20) AAS
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの

500: 2020/05/16(土)12:30 ID:e+rgeli+(3/20) AAS
>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ

501: 2020/05/16(土)12:34 ID:e+rgeli+(4/20) AAS
普通、ParseForm が判定して取り込むよね
なんで分離してんの？

502(1): 2020/05/16(土)13:02 ID:e+rgeli+(5/20) AAS
エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

ショボい作りだ

503: 2020/05/16(土)13:05 ID:e+rgeli+(6/20) AAS
request.go の中身を初めて見たけど、エラー処理は雑だし残念すぎるなコレ

505: 2020/05/16(土)13:14 ID:e+rgeli+(7/20) AAS
>>504
ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから

507: 2020/05/16(土)14:59 ID:e+rgeli+(8/20) AAS
なのかな？よく知らない

でも、WebAPIでFormとしてデータを受けるときはParseFormの使用が罠なのは確実
それともbodyを自分で解析するのが定石だったりする？

512: 2020/05/16(土)16:52 ID:e+rgeli+(9/20) AAS
>>511
何のメリットがあって呼ぶ方が判定しなければならないのか、教えてください

515(1): 2020/05/16(土)17:34 ID:e+rgeli+(10/20) AAS
自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている

しかし、例えば文字コードの自動判定ではSJISとUTF-8のどちらでも有効であるマルチバイト文字が存在する
例)"【D"と"縲識"はどちらも E3 80 90 44

このようなケースがある課題では自動処理できないので、ライブラリの外側で何かしらの対応をしてやる必要がある
マルチパートFormという課題でも同じように呼ぶ方が対処してやらなければならない問題があるのだろうと思った

だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？

516(1): 2020/05/16(土)17:40 ID:e+rgeli+(11/20) AAS
505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから

521: 2020/05/16(土)17:55 ID:e+rgeli+(12/20) AAS
ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど

maxMemory引数はデフォルト値を中に持って、オプションとして変更できるようにするのが、こういったライブラリの定石だから(ソケットのタイムアウト時間設定とか)、これは問題点じゃない
いや引数の設計上の問題点だけど

522: 2020/05/16(土)18:06 ID:e+rgeli+(13/20) AAS
>>520
それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう

FormDataオブジェクトを使うと発生するContent-Typeくらい自動で処理しないライブラリってどうなの？

525(1): 2020/05/16(土)18:28 ID:e+rgeli+(14/20) AAS
>>523
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？

527: 2020/05/16(土)18:49 ID:e+rgeli+(15/20) AAS
あ、それ違う

それはParseForm(1180行あたり)から呼ばれる奴だ
つまりマルチパート非対応

ParseMultipartForm(1294行あたり)から呼ばれるmultipartReader(480行あたり)ではContent-Typeが無いと、やっぱりエラーを叩き返してる

528: 2020/05/16(土)18:53 ID:e+rgeli+(16/20) AAS
つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している

529: 2020/05/16(土)18:57 ID:e+rgeli+(17/20) AAS
ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる

530(1): 2020/05/16(土)19:07 ID:e+rgeli+(18/20) AAS
意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう

532(1): 2020/05/16(土)21:02 ID:e+rgeli+(19/20) AAS
>>531
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる

533(3): 2020/05/16(土)21:30 ID:e+rgeli+(20/20) AAS
最終的に

func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if v == "" {
return i.request.ParseForm()
} else {
return i.request.ParseMultipartForm(100 * 1024)
}
}

とすることにした

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.052s