[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
497: デフォルトの名無しさん [sage] 2020/05/16(土) 11:46:57.57 ID:e+rgeli+(1/20) AAS
1.12 の http/request.go に、でっかい落とし穴が
こいつは、1210 行目で ContextType == "multipart/form-data" の処理が未実装
そして、 Chrome は FormData オブジェクトを XMLHttpRequest で send() すると問題のマルチパートで送りつける
よって、FormData は使えない……
他のブラウザだとどうなんだろ？困るな
499: デフォルトの名無しさん [sage] 2020/05/16(土) 12:29:08.12 ID:e+rgeli+(2/20) AAS
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの
500: デフォルトの名無しさん [sage] 2020/05/16(土) 12:30:20.91 ID:e+rgeli+(3/20) AAS
>>498498(1): デフォルトの名無しさん [sage] 2020/05/16(土) 12:28:15.83 ID:bJ5k+aLx(1/6) AAS
xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
じゃダメなん？
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ
501: デフォルトの名無しさん [sage] 2020/05/16(土) 12:34:33.17 ID:e+rgeli+(4/20) AAS
普通、ParseForm が判定して取り込むよね
なんで分離してんの？
502(1): デフォルトの名無しさん [sage] 2020/05/16(土) 13:02:51.76 ID:e+rgeli+(5/20) AAS
エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す
ショボい作りだ
503: デフォルトの名無しさん [sage] 2020/05/16(土) 13:05:20.47 ID:e+rgeli+(6/20) AAS
request.go の中身を初めて見たけど、エラー処理は雑だし残念すぎるなコレ
505: デフォルトの名無しさん [sage] 2020/05/16(土) 13:14:14.23 ID:e+rgeli+(7/20) AAS
>>504ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから
507: デフォルトの名無しさん [sage] 2020/05/16(土) 14:59:51.10 ID:e+rgeli+(8/20) AAS
なのかな？よく知らない
でも、WebAPIでFormとしてデータを受けるときはParseFormの使用が罠なのは確実
それともbodyを自分で解析するのが定石だったりする？
512: デフォルトの名無しさん [sage] 2020/05/16(土) 16:52:50.26 ID:e+rgeli+(9/20) AAS
>>511何のメリットがあって呼ぶ方が判定しなければならないのか、教えてください
515(1): デフォルトの名無しさん [sage] 2020/05/16(土) 17:34:03.50 ID:e+rgeli+(10/20) AAS
自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている
しかし、例えば文字コードの自動判定ではSJISとUTF-8のどちらでも有効であるマルチバイト文字が存在する
例)"【D"と"縲識"はどちらも E3 80 90 44
このようなケースがある課題では自動処理できないので、ライブラリの外側で何かしらの対応をしてやる必要がある
マルチパートFormという課題でも同じように呼ぶ方が対処してやらなければならない問題があるのだろうと思った
だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？
516(1): デフォルトの名無しさん [sage] 2020/05/16(土) 17:40:18.88 ID:e+rgeli+(11/20) AAS
505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから
521: デフォルトの名無しさん [sage] 2020/05/16(土) 17:55:54.20 ID:e+rgeli+(12/20) AAS
ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど
maxMemory引数はデフォルト値を中に持って、オプションとして変更できるようにするのが、こういったライブラリの定石だから(ソケットのタイムアウト時間設定とか)、これは問題点じゃない
いや引数の設計上の問題点だけど
522: デフォルトの名無しさん [sage] 2020/05/16(土) 18:06:23.99 ID:e+rgeli+(13/20) AAS
>>520それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう
FormDataオブジェクトを使うと発生するContent-Typeくらい自動で処理しないライブラリってどうなの？
525(1): デフォルトの名無しさん [sage] 2020/05/16(土) 18:28:03.02 ID:e+rgeli+(14/20) AAS
>>523523(1): デフォルトの名無しさん [sage] 2020/05/16(土) 18:13:07.38 ID:bJ5k+aLx(4/6) AAS
request.parsePostForm() は Content-Type が無ければ application/octet-stream と見なす様だ
func parsePostForm(r *Request) (vs url.Values, err error) {
:
ct := r.Header.Get("Content-Type")
// RFC 7231, section 3.1.1.5 - empty type
// MAY be treated as application/octet-stream
if ct == "" {
ct = "application/octet-stream"
}
ct, _, err = mime.ParseMediaType(ct)
:
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？
527: デフォルトの名無しさん [sage] 2020/05/16(土) 18:49:32.90 ID:e+rgeli+(15/20) AAS
あ、それ違う
それはParseForm(1180行あたり)から呼ばれる奴だ
つまりマルチパート非対応
ParseMultipartForm(1294行あたり)から呼ばれるmultipartReader(480行あたり)ではContent-Typeが無いと、やっぱりエラーを叩き返してる
528: デフォルトの名無しさん [sage] 2020/05/16(土) 18:53:01.16 ID:e+rgeli+(16/20) AAS
つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している
529: デフォルトの名無しさん [sage] 2020/05/16(土) 18:57:51.02 ID:e+rgeli+(17/20) AAS
ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる
530(1): デフォルトの名無しさん [sage] 2020/05/16(土) 19:07:51.23 ID:e+rgeli+(18/20) AAS
意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう
532(1): デフォルトの名無しさん [sage] 2020/05/16(土) 21:02:30.65 ID:e+rgeli+(19/20) AAS
>>531531(1): デフォルトの名無しさん [sage] 2020/05/16(土) 19:47:58.26 ID:F08ATzLT(4/4) AAS
>>530
content-typeがない場合
Request.Bodyの内容からapplication/x-www-form-urlencodedやmultipart/form-dataなどのデータ形式（content-type相当）を判断する必要がる。
multipart/form-dataに限ってはboundaryをRequest.Body内容から見つけ出す必要がある。
（keyValueを取得するにもboundaryが必要。）
で、ここで問題なのがRequest.BodyはSTDINからの入力でseekが出来ないのでデータ形式判定後に再度Request.Bodyを読み込むために何らかの方法でRequest.Bodyをキャッシュする必要が出てくる。
（multipart/form-dataはファイルもアップロード出来るのでメモリ上でのキャッシュには向かない）
それとhttp.Serverは常駐プロセスになるので、無駄なリソースを使って自動判別して自動でパースするよりcontent-typeで分岐してパースする方が合理的。
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる
533(3): デフォルトの名無しさん [] 2020/05/16(土) 21:30:32.48 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.042s