Go language part 3

■ このスレッドは過去ログ倉庫に格納されています
2019/10/17(木) 21:38:04.78ID:wMsZ+t6y
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式ドキュメント
http://golang.org/doc/

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/
2020/04/23(木) 10:36:37.69ID:AGd9KY8X
>>435
完全にコーダーの発想だな
2020/04/23(木) 10:37:35.02ID:6AabYYA1
>>433
ああ、そういえばCとかではエントリがmain関数だったのが、クラスになっているスタイルもJavaで覚えた
そのためC#でもほぼ同じだから、そこで引っ掛かることが無かった
そういう観点であってifとかforなどの構文じゃないよ
2020/04/23(木) 10:39:55.23ID:6AabYYA1
>>436
笑わせるなよ
学習コストの話なんだからコーダー視点に決まってるだろ
2020/04/23(木) 10:55:34.68ID:AGd9KY8X
キチガイに触ってしまったごめんなさい
2020/04/23(木) 10:55:50.60ID:3P7Oolim
JavaとC#では技術スタックが全然違うだろう
サーバーの構築から通信方法からフレームワーク等の選定から何から、
そういう足回りを全部すっ飛ばして全部あらかじめ他人に与えられた環境を使って
「さあ、アプリケーションコードを書いてください」ならそら大差ないだろ
俺は436じゃないが「コーダー」ってそういう意味じゃないかな
2020/04/23(木) 11:30:36.92ID:1fYIb7dj
ハゲしくスレ違い
2020/04/23(木) 14:11:43.18ID:6AabYYA1
出だしが学習コストの話で、人格攻撃やらサーバの構築とか的外れな事を言い出してくるやら
詭弁術だけはお得意なことはよくわかりました
2020/04/25(土) 02:28:33.10ID:wAZrgsxC
ギスギスしててワロ
Goは誰でもある程度のレベルくらいまでなら使いこなせる優しい言語
2020/04/26(日) 19:49:45.56ID:xNjL7Ex+
ものすごく当たり前の落とし穴に落ちた

ファクトリから構造体アドレス返してたのをインタフェース返すように変更したらテストでコケた
キャストチェックのテストだったんだけど、レシーバのシグネチャが同じ別のインタフェースがあって、そいつにキャストできちゃった

インタフェースが同じなら同じものとして使えるってことは、そういう問題を想定しとかないとならなかった
2020/04/28(火) 19:31:28.17ID:Ce9HOSET
大きくなってきたんでパッケージを分割

設定とか全体を管理するAパッケージ
httpのリクエストを管理するBパッケージ
webAPIのロジックを管理するCパッケージ
ロジックのインスタンスは設定で作って、リクエストから呼び出して処理してもらう

さて、ここで落とし穴
Cパッケージから設定を参照するためにAパッケージをインポートすると import cycle not arrowed 発生
AパッケージではCパッケージをインポートして、ロジックのファクトリを呼び出してる

インポートの循環の制約とか、それは厳しすぎやしませんかね
第三の上位パッケージを作ればなんとかなるのかなぁ？
2020/04/28(火) 20:20:55.63ID:iogl+PJs
arrowed ?
447デフォルトの名無しさん
垢版 |
2020/04/28(火) 20:31:42.46ID:ghSBG3zr
>>445
Goに限らずモジュール境界はインタフェースで抽象化するもんじゃ？
そうしないとユニットテストつらい
2020/04/28(火) 20:48:56.59ID:SLRJSTJf
> 設定とか全体を管理するパッケージ
インターフェース云々以前に、そんなふわっとしたモジュール強度の低いパッケージが存在することが問題
設定なら設定で分けろ
設定はデータ構造自体がインターフェイスなんだからカプセル化とか要らん
2020/04/28(火) 20:51:51.61ID:OCson2MM
>>445
AからC呼び出すっておかしいだろ
設計やり直せ
2020/04/28(火) 22:00:57.39ID:Ce9HOSET
>>449
ロジックのインタフェースの実体を得るファクトリ関数なんだがおかしいのか？

でも、そもそもが設定情報のパッケージにシステムを管理するデータの生成を担わせてる設計が原因臭いとはうすうす
やっぱそこを別パッケージに分離して結合を弱めないとだめだな
2020/04/28(火) 22:23:30.36ID:Ce9HOSET
結局、日和ってロジックのインスタンスはCパッケージにシングルトンとして実装してBから呼ぶことでallowedを回避した
根本的な解決ではないが、動けばいい！(うわっ自分で言ってて恥ずかしい
2020/05/01(金) 06:16:44.51ID:txiwXjh+
VScodeなのかdelveなのか、デバッガでスライスを見たとき64個までしか見えません
どこの設定を弄れば最後まで見せてもらえるのか、調べてみたけれど分かりません
→ githubのgo-delveとかvscode-goとか
このカスタマイズについて情報があれば教えてください
453デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:36:26.80ID:txiwXjh+
各プラットフォームのランタイムのせいだろうとは思うけど・・・
io パッケージの
func Copy(dst Writer, src Reader) (written int64, err error)
と
type Writer interface {
Write(p []byte) (n int, err error)
}
で戻り値に一貫性がない事に気づいて、ちょっとイラっときた

(io.Writer).Write() では n の合計が len(p) になるまで繰り返さないとダメ？
かと思ったけど、
Write must return a non-nil error if it returns n < len(p).
って書いてあるよ・・・
454デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:43:36.06ID:txiwXjh+
ああっ
The built-in functions len and cap take arguments of various types and return a result of type int.
だからなのか

いいのかそんな仕様で
2020/05/01(金) 12:06:06.92ID:Ia4c8IgS
Goではintのサイズと配列の最大長は環境依存だからそれで正しい
そして、CopyはWriteを一発呼ぶだけじゃなくて指定された長さをコピーし終えるまで読み書きを繰り返すように実装するもの
だから配列の最大長とか無関係
やってることが全然違うんだから一貫性もクソもない
2020/05/01(金) 12:20:25.30ID:OD5xAYpx
Rob Pike interview: “Go has become the language of cloud infrastructure”
https://evrone.com/rob-pike-interview
2020/05/01(金) 13:10:50.80ID:txiwXjh+
>指定された長さ
ダウト
Copy見てきてください

こいつはReaderからバイトストリーム(厳密には意訳)をEOFに達するまでWriterに書き込み、その書き込みバイト数を返します
サイズなんて指定しません

Writerに書き出すソースが固定のスライスではないだけで、Writerに書き出すという目的から見ればWriteと同じでしょ
まあ違うとあえて言うなら、私とあなたは考え方が違うんでしょうね (私は「何をするか」という目的で言ったので)
2020/05/01(金) 23:48:52.57ID:txiwXjh+
log.Logger の出力でファイル名も出させるようにして気づいたけど、ソースファイルのパスって実行ファイルの中にしっかりと記録されてる？

Loggerでファイル名を指定すると内部でruntime.Caller呼んでスタック情報拾うんだけど
ログにはソースファイルの完全パスがしっかりと出てくる
実行ファイルを別ディレクトリはにコピーして実行しても出るから、実行ファイルの置き場所を利用している訳じゃない
また、runtimeパッケージがソースファイル情報をもってる訳もないからリンカが埋め込んでるんだろうと推測
runtimeパッケージを使う使わないで、リンカが埋め込む埋め込まないを切り替えるなんて器用な真似はさせていないだろうし
だとすると、ソースファイルの情報って全て記録されているはず(stringsで実行ファイルの中を見た訳じゃないけど)
という推測

完全パスで困るのはユーザ名がしっかり出ちゃうことなんだよな
それが嫌ならユーザディレクトリで開発するなという事なのか
459デフォルトの名無しさん
垢版 |
2020/05/02(土) 08:59:25.19ID:+Au1iQ6P
みんなはGW中は嫁さんとセックスしまくりなの？
独身の俺からすると羨ましいんだけど
2020/05/02(土) 13:46:40.57ID:iDDOId/p
嫁さんとセクロスなんて1年で飽きるぞ
461デフォルトの名無しさん
垢版 |
2020/05/02(土) 14:11:11.13ID:H63qqmuN
セクロスはセフレとしかしないな
2020/05/02(土) 14:12:11.64ID:1t1QmWMu
疲れるだけだぞ
2020/05/02(土) 14:21:57.66ID:z5TAOMiI
飽きるか？全然飽きないんだが。
嫁ともっとセクロスしたいわ。
2020/05/02(土) 14:26:10.42ID:jSLKT64y
　　　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　　　 (　 　,,)┌─┴┴─┐
　　　　　　　/　　　つ.　 終　 了 │
　　　　　〜′　/´　└─┬┬─┘
　　　　　　∪ ∪　　　 　 ││　_ε３
　　　　　　　　　　　　　　 ゛゛'゛'゛
2020/05/02(土) 16:06:20.88ID:3+K3/vn9
GoのスレなんだからせめてGopherくんで抜けるかどうかの議論しろよ
2020/05/02(土) 16:30:21.85ID:1t1QmWMu
gopherくんみたいな女いるよな
目がでかくて歯並び悪いやつ　

抜ける
2020/05/02(土) 17:53:36.77ID:+BhrZUVp
常駐しつつ標準入力からのコマンドを受け付ける構成のプログラム書いてる
だけど、デバッグターミナルからの標準入力はサポートされないんだな(vscode-go/
issues/219)
VScodeの問題かと探したのにdelveの問題？
2020/05/02(土) 17:56:31.80ID:+BhrZUVp
ちなみにシグナル使えという話は横に置いといてね
os.Interruptとかのハンドリングはもう入ってる
Windowsでkillしても受け取らないんだこれが
2020/05/08(金) 09:06:51.86ID:+d3XVyIT
「プログラミング言語Go完全入門」の期間限定公開のお知らせ
https://tech.mercari.com/entry/2020/03/17/120137

PDF版もあるよ
2020/05/08(金) 09:16:00.33ID:le9A8gSm
どうでもいい内容なんだよなーそれ
2020/05/08(金) 09:28:21.26ID:/imhMepR
ところどころ抜けてて口頭説明前提の作りで肝心な内容が無い資料公開されてもな
472デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:47:37.47ID:oIDbptWL
>>469
ʕ ◔ϖ◔ʔ
ありがたや

人
473デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:48:51.29ID:oIDbptWL
https://qiita.com/mattn/items/b7889e3c036b408ae8bd
474デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:50:21.63ID:oIDbptWL
https://write.kogus.org/articles/S78LHt
2020/05/08(金) 16:04:03.09ID:SpWQlQbz
言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし
2020/05/08(金) 18:12:47.83ID:QcJ6udj9
>>475
みんなのGoは、flagパッケージとかの使用例が役に立った
よく言われるように初心者向けではないだろうなとも思った
2020/05/08(金) 22:59:05.96ID:tAyMPd7a
Golang逆引きレシピ（version1.14対応）

って本出してくれ
kindleで5000円までなら買う
2020/05/09(土) 18:13:17.56ID:m4Vh3zrv
2.0はいつリリースされますのん？
2020/05/09(土) 18:28:27.39ID:4jg1EkWA
予定は未定
2020/05/09(土) 19:27:11.31ID:CUL9xwyE
開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。
2020/05/10(日) 09:38:46.23ID:XQ0sO87J
サーバで使われることが割と一般的なコンパイル言語（Java以外）って
Go以外になんかあったっけ
482デフォルトの名無しさん
垢版 |
2020/05/10(日) 11:01:30.61ID:hDQHcieg
apache は何でコンパイルされてる？
2020/05/10(日) 11:02:41.97ID:ot41mX7+
C#
海外を含めるならWin鯖除外でも今やGoよりは多いんじゃないか
2020/05/10(日) 11:59:28.84ID:XQ0sO87J
>>482
訂正、サーバでバックエンドとして
C#かー
2020/05/10(日) 13:04:42.48ID:+Vdduh76
C++
2020/05/10(日) 14:28:40.79ID:p9tAaMVr
Javaじゃね？って言葉を無視するのであれば、Scalaは聞いたことある。
487デフォルトの名無しさん
垢版 |
2020/05/10(日) 15:35:37.07ID:FhPtT+Xo
コンパイル言語で伸びそうなのはKotlin
2020/05/10(日) 18:14:39.27ID:onDYsAIY
javaがinnullable化すればいいんだ
いつ達成されるのか
2020/05/10(日) 18:21:05.86ID:BbBbqgLD
凄いスレ違い
2020/05/13(水) 07:56:28.24ID:p0Yu02SZ
Goは学習コストが少ないっていう嘘に騙されてるやつとそう信じてる信者が多いのが最大の失敗
コード読むだけじゃ見落とすような罠が簡単につくれるし直感的に分かりづらい仕様と機能不足が多すぎる
書き捨てるだけなら簡単だがチーム開発で採用するには残念すぎる言語
2020/05/13(水) 08:32:08.19ID:Q3kP6cCa
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
2020/05/13(水) 08:34:54.68ID:+HM7ZWjz
見えない罠が多すぎる言語よりは数段マシなんだよな
2020/05/14(木) 17:27:46.77ID:ljUxN++I
>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった

あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった
2020/05/15(金) 00:10:35.84ID:WhbhAQET
>>490
他と比べたら、って話でしょ
2020/05/15(金) 01:28:18.31ID:kU/eypzI
>>493
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる
2020/05/15(金) 05:05:48.78ID:02fpr2+t
>>495
あ、脊椎で反射的に反論しそうになったけど指摘されてみると全くその通りだね
ファクトリからインタフェースを返すのは悪手だわこれ
2020/05/16(土) 11:46:57.57ID:e+rgeli+
1.12 の http/request.go に、でっかい落とし穴が

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

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

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

他のブラウザだとどうなんだろ？困るな
2020/05/16(土) 12:28:15.83ID:bJ5k+aLx
xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );

じゃダメなん？
2020/05/16(土) 12:29:08.12ID:e+rgeli+
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの
2020/05/16(土) 12:30:20.91ID:e+rgeli+
>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ
2020/05/16(土) 12:34:33.17ID:e+rgeli+
普通、ParseForm が判定して取り込むよね
なんで分離してんの？
2020/05/16(土) 13:02:51.76ID:e+rgeli+
エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

ショボい作りだ
2020/05/16(土) 13:05:20.47ID:e+rgeli+
request.go の中身を初めて見たけど、エラー処理は雑だし残念すぎるなコレ
2020/05/16(土) 13:11:02.15ID:bJ5k+aLx
request.MultipartReader() の方を使ってみたら
2020/05/16(土) 13:14:14.23ID:e+rgeli+
>>504
ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから
2020/05/16(土) 14:52:00.85ID:9I4cSVvN
マルチパートって、要は多段formだっけ
2020/05/16(土) 14:59:51.10ID:e+rgeli+
なのかな？よく知らない

でも、WebAPIでFormとしてデータを受けるときはParseFormの使用が罠なのは確実
それともbodyを自分で解析するのが定石だったりする？
2020/05/16(土) 15:12:59.98ID:F08ATzLT
>>502
＞ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

これは正常な処理だよ
Context-Typeが"multipart/form-data" の場合
Context-Type のmultipart/form-dataの後に続くboundaryをキーにしてmultipartをパースするんだから
ParseMultipartFormがContext-Typeからパースに必要なboundaryを取得できなくてエラーになるのはいたって正常なことだよ
2020/05/16(土) 15:26:41.59ID:F08ATzLT
>>508の補足
Content-Typeが無かったらboundaryが取得できないのにParseMultipartFormでパースしようとするからエラーを返す
2020/05/16(土) 15:30:06.54ID:9I4cSVvN
「この中にformがいっぱい入ってますよ」っていうformなんだよね
2020/05/16(土) 15:43:30.65ID:F08ATzLT
ヘッダーのContext-Typeで分岐して適切なParseなにがしを呼べってことです。
2020/05/16(土) 16:52:50.26ID:e+rgeli+
>>511
何のメリットがあって呼ぶ方が判定しなければならないのか、教えてください
2020/05/16(土) 17:00:10.79ID:9I4cSVvN
駄々こねてるようにしか見えんぞ
2020/05/16(土) 17:24:44.07ID:bJ5k+aLx
う〜ん、Context-Type が指定されていないのに multipart を自動判別して
くれるライブラリとかフレームワークって他所の言語にあったりするのかな…？
2020/05/16(土) 17:34:03.50ID:e+rgeli+
自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている

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

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

だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？
2020/05/16(土) 17:40:18.88ID:e+rgeli+
505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから
517デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:40:39.14ID:is04b0b3
MIME Type
MIME Encoding
2020/05/16(土) 17:45:07.11ID:GaPEU8I0
それはバウンダリの中身に、
Content-disposition: attachment; filename="xxxxx"
Content-Type: text/plain
なんかが書いてあるからできる動作であって、実はバウンダリの中身はかなり自由。
マルチパートの中にさらにマルチパートを入れるマトリョーシカのようなことをしてもかまわん。仕様上は。
これをきれいに自動でデシリアライズするのは結構難しいと思うけど。
そういう意味では、呼ぶ側が解釈を与えないといかんって割り切りは間違っちゃないんじゃないか？
他のコンパイル言語でどう対応してるのか気になるな。
2020/05/16(土) 17:51:34.17ID:9I4cSVvN
仕事でAWSのAPI Gatewayって機能使った時に
マルチパートフォームデータだけは解釈してくれなかった
クラウドサービスの都合上外部のライブラリ入れるにはソースに同梱するしか無く、
それは嫌だったからバックエンドのLambda（goに対応しているけど仕事で使ったのは非go）で
自前でバウンダリのfrom-toを切り取った上でガン無視してリクエストbodyを拾うだけの処理を書いた記憶があるｗ
完全にスレチだけど
2020/05/16(土) 17:54:45.69ID:4LNE0T1O
>>515
だってContent-Typeに現れるのはその2種類だけとは限らないから全部ライブラリ任せにはできんだろ。
2020/05/16(土) 17:55:54.20ID:e+rgeli+
ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど

maxMemory引数はデフォルト値を中に持って、オプションとして変更できるようにするのが、こういったライブラリの定石だから(ソケットのタイムアウト時間設定とか)、これは問題点じゃない
いや引数の設計上の問題点だけど
2020/05/16(土) 18:06:23.99ID:e+rgeli+
>>520
それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう

FormDataオブジェクトを使うと発生するContent-Typeくらい自動で処理しないライブラリってどうなの？
2020/05/16(土) 18:13:07.38ID:bJ5k+aLx
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)
:
2020/05/16(土) 18:26:33.81ID:bJ5k+aLx
RFC 7231 HTTP/1.1: Semantics and Content（日本語訳）
https://triple-underscore.github.io/RFC7231-ja.html#section-3.1.1.5

> 実施においては、リソースの所有者は、[生成元サーバが[所与の表現用
> に正しい Content-Type を供する]ように、常に適正に環境設定されてい
> る]とは限らないため、クライアントには、[ペイロードの内容を精査し
> て、指定された型を上書きする]ものもある【例:MIME sniffing】。その
> ようにするクライアントは、不正な結論を導くリスクを負い、追加のセ
> キュリティリスクを公開し得る(例:"特権拡大")。更には、送信者の意図
> をデータ形式を精査して決定するのは、不可能である: 多くのデータ形
> 式は、処理の意味論においてのみ相違するような、複数の MIME 型に合
> 致する。実装者には、そのような "内容 sniff 法" を利用するときは、
> それを不能化する手段を供することが奨励される。
2020/05/16(土) 18:28:03.02ID:e+rgeli+
>>523
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？
2020/05/16(土) 18:35:18.02ID:bJ5k+aLx
>>525
GitHub リポジトリの develop branch から引っ張ってビルドしたもの

$ go version
go version devel +810c27e9be Wed May 13 11:59:26 2020 +0000
2020/05/16(土) 18:49:32.90ID:e+rgeli+
あ、それ違う

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

ParseMultipartForm(1294行あたり)から呼ばれるmultipartReader(480行あたり)ではContent-Typeが無いと、やっぱりエラーを叩き返してる
2020/05/16(土) 18:53:01.16ID:e+rgeli+
つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している
2020/05/16(土) 18:57:51.02ID:e+rgeli+
ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる
2020/05/16(土) 19:07:51.23ID:e+rgeli+
意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう
2020/05/16(土) 19:47:58.26ID:F08ATzLT
>>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で分岐してパースする方が合理的。
2020/05/16(土) 21:02:30.65ID:e+rgeli+
>>531
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる
533デフォルトの名無しさん
垢版 |
2020/05/16(土) 21:30:32.48ID:e+rgeli+
最終的に

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)
}
}

とすることにした
2020/05/17(日) 07:48:09.08ID:8deP89zB
>>532
> としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？

そもそもParseFormがリクエストのパース処理を包括したラッパー関数だと何処で勘違いしたの？

なぜそこまで頑なにRequest-MethodとContent-Typeの値で分岐しようとしないの？
（Content-Typeの値の有無だけ確認して分岐したって言うのは無しよ）

>>533のあなたの最終的な実装を見るとあなたはContent-TypeとParseFormとParseMultipartFormを理解して使って無いの、何となく動くからってやっつけで実装したようにしか見えないの。
2020/05/17(日) 07:48:39.85ID:8deP89zB
>>533
あなたの最終的な実装を元にして実装するならこんな感じかな（勝ってに拡張しちゃってるけど）
func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
ct, _, err = mime.ParseMediaType(ct)
if err == nil {
switch ct {
case "multipart/form-data":
if r.Method == "POST" {
err = r.ParseMultipartForm(100 * 1024)
} else {
err = errors.New(“invalid request”)
}
case “application/json”:
d := json.NewDecoder(r.Body)
// i.Json = make(map[string]interface{})
i.Json = &BindStructure{}
err = d.Decode(&i.Json)
default:
err = r.ParseForm()
}
}
return err
}

まぁ、頑張って。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況