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/19(日) 19:53:26.80ID:GbCXYg+t
だが断るっ！
2020/04/22(水) 17:15:41.53ID:2MssAlkL
流石にJavaやScalaからGo移行とかになるとあまりの言語機能のゴミっぷりに開発者がキレそう
今までハサミつかって紙きってたのに石器渡されるようもんだわ
2020/04/22(水) 17:57:25.70ID:gFNuxdvi
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
2020/04/22(水) 18:22:16.77ID:LU+JwGqd
この言語はCでサーバを書いているようなニッチな要求の仕事を置き換えるんだろうな

なに？そんな仕事があるわけない？
…去年回って来ちゃってたよ、そんな仕事が
ミリ秒縛り要求で数十の機器の管制をするサーバ
当時はgo知らなかったんでgccで書いた
427デフォルトの名無しさん
垢版 |
2020/04/22(水) 19:29:43.68ID:5I5B70Wh
リアルタイム性重視なら、GCあるGoは向いてないんじゃ
その用途で置き換えるならRustになりそう
2020/04/22(水) 20:01:17.39ID:LU+JwGqd
Goは半日で理解できたがRustは無理だった
2020/04/23(木) 00:05:34.25ID:b8mXccsZ
鯖は比較的余裕有るけど、クライアント側でGCが痛い子になる事はありそう
Rustは半日では無理だなぁ〜、概念は直ぐ理解出来るけど書き方に統一感無さ過ぎてキレそう<'a>&'a *ref
2020/04/23(木) 00:49:14.99ID:3qWTs6XO
Rustは人類には早すぎる
2020/04/23(木) 00:55:50.26ID:1fYIb7dj
禿しく同意
2020/04/23(木) 08:01:42.02ID:6AabYYA1
Rustはバカ速いとか聞くから覚えたいんだけど
学習コストもバカ高いよなぁ
CとかPascalやっててJavaを始めたときの倍くらい大変な感じがする
C#はJavaを丸パクりで基本構文ができてたから、１日
2020/04/23(木) 08:06:05.23ID:AGd9KY8X
そりゃあif文for文みたいなコードだけなら1日だろうよ
2020/04/23(木) 08:41:47.89ID:Q66hfIcW
rust、利便性のためにライフタイムの省略パターンとか作ったんだろうけれど、逆にわかりづらくなってるわ。
2020/04/23(木) 10:29:03.11ID:6AabYYA1
>>433
クラスの定義の書き方とかもだよ
Javaでない言語のクラスの書き方は、クラス定義にはメソッドの宣言を書いて、定義の外で実装するスタイルが主流だった(他の言語には無いとは言わないが非主流)
これはC++とかObjectPASCAL、そしてGoもこちらのスタイルではある

C#では、基本的にデフォルト仮想なJavaメソッドに対して、デフォルトは非仮想って程度の差(充分にでかい差ではある、ちなみにジェネリックはまだない時分)
だから、覚えるというより慣れるのに１日
SalesforceのAPECはまた面白くて構文はC#以上にJavaなのにデフォルト非仮想だったかな
よく似た兄弟すぎて、仕事とプライベートそれぞれ違う言語で書いてると混乱する
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)
:
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況