Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

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

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/

**デフォルトの名無しさん** · 2020/05/01(金) 11:36:26.80

各プラットフォームのランタイムのせいだろうとは思うけど・・・
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).
って書いてあるよ・・・

**デフォルトの名無しさん** · 2020/05/01(金) 11:43:36.06

ああっ
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.92

Goではintのサイズと配列の最大長は環境依存だからそれで正しい
そして、CopyはWriteを一発呼ぶだけじゃなくて指定された長さをコピーし終えるまで読み書きを繰り返すように実装するもの
だから配列の最大長とか無関係
やってることが全然違うんだから一貫性もクソもない

**デフォルトの名無しさん** · 2020/05/01(金) 12:20:25.30

Rob Pike interview: “Go has become the language of cloud infrastructure”
https://evrone.com/rob-pike-interview

**デフォルトの名無しさん** · 2020/05/01(金) 13:10:50.80

>指定された長さ
ダウト
Copy見てきてください

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

Writerに書き出すソースが固定のスライスではないだけで、Writerに書き出すという目的から見ればWriteと同じでしょ
まあ違うとあえて言うなら、私とあなたは考え方が違うんでしょうね (私は「何をするか」という目的で言ったので)

**デフォルトの名無しさん** · 2020/05/01(金) 23:48:52.57

log.Logger の出力でファイル名も出させるようにして気づいたけど、ソースファイルのパスって実行ファイルの中にしっかりと記録されてる？

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

完全パスで困るのはユーザ名がしっかり出ちゃうことなんだよな
それが嫌ならユーザディレクトリで開発するなという事なのか

**デフォルトの名無しさん** · 2020/05/02(土) 08:59:25.19

みんなはGW中は嫁さんとセックスしまくりなの？
独身の俺からすると羨ましいんだけど

**デフォルトの名無しさん** · 2020/05/02(土) 13:46:40.57

嫁さんとセクロスなんて1年で飽きるぞ

**デフォルトの名無しさん** · 2020/05/02(土) 14:11:11.13

セクロスはセフレとしかしないな

**デフォルトの名無しさん** · 2020/05/02(土) 14:12:11.64

疲れるだけだぞ

**デフォルトの名無しさん** · 2020/05/02(土) 14:21:57.66

飽きるか？全然飽きないんだが。
嫁ともっとセクロスしたいわ。

**デフォルトの名無しさん** · 2020/05/02(土) 14:26:10.42

　　　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　　　 (　　,,)┌─┴┴─┐
　　　　　　　/　　　つ.　終　了 │
　　　　　～′　/´　└─┬┬─┘
　　　　　　∪ ∪　　　　 ││　_ε３
　　　　　　　　　　　　　　゛゛'゛'゛

**デフォルトの名無しさん** · 2020/05/02(土) 16:06:20.88

GoのスレなんだからせめてGopherくんで抜けるかどうかの議論しろよ

**デフォルトの名無しさん** · 2020/05/02(土) 16:30:21.85

gopherくんみたいな女いるよな
目がでかくて歯並び悪いやつ　

抜ける

**デフォルトの名無しさん** · 2020/05/02(土) 17:53:36.77

常駐しつつ標準入力からのコマンドを受け付ける構成のプログラム書いてる
だけど、デバッグターミナルからの標準入力はサポートされないんだな(vscode-go/
issues/219)
VScodeの問題かと探したのにdelveの問題？

**デフォルトの名無しさん** · 2020/05/02(土) 17:56:31.80

ちなみにシグナル使えという話は横に置いといてね
os.Interruptとかのハンドリングはもう入ってる
Windowsでkillしても受け取らないんだこれが

**デフォルトの名無しさん** · 2020/05/08(金) 09:06:51.86

「プログラミング言語Go完全入門」の期間限定公開のお知らせ
https://tech.mercari.com/entry/2020/03/17/120137

PDF版もあるよ

**デフォルトの名無しさん** · 2020/05/08(金) 09:16:00.33

どうでもいい内容なんだよなーそれ

**デフォルトの名無しさん** · 2020/05/08(金) 09:28:21.26

ところどころ抜けてて口頭説明前提の作りで肝心な内容が無い資料公開されてもな

**デフォルトの名無しさん** · 2020/05/08(金) 09:47:37.47

>>469
ʕ ◔ϖ◔ʔ
ありがたや

人

**デフォルトの名無しさん** · 2020/05/08(金) 09:48:51.29

https://qiita.com/mattn/items/b7889e3c036b408ae8bd

**デフォルトの名無しさん** · 2020/05/08(金) 09:50:21.63

https://write.kogus.org/articles/S78LHt

**デフォルトの名無しさん** · 2020/05/08(金) 16:04:03.09

言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし

**デフォルトの名無しさん** · 2020/05/08(金) 18:12:47.83

>>475
みんなのGoは、flagパッケージとかの使用例が役に立った
よく言われるように初心者向けではないだろうなとも思った

**デフォルトの名無しさん** · 2020/05/08(金) 22:59:05.96

Golang逆引きレシピ（version1.14対応）

って本出してくれ
kindleで5000円までなら買う

**デフォルトの名無しさん** · 2020/05/09(土) 18:13:17.56

2.0はいつリリースされますのん？

**デフォルトの名無しさん** · 2020/05/09(土) 18:28:27.39

予定は未定

**デフォルトの名無しさん** · 2020/05/09(土) 19:27:11.31

開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。

**デフォルトの名無しさん** · 2020/05/10(日) 09:38:46.23

サーバで使われることが割と一般的なコンパイル言語（Java以外）って
Go以外になんかあったっけ

**デフォルトの名無しさん** · 2020/05/10(日) 11:01:30.61

apache は何でコンパイルされてる？

**デフォルトの名無しさん** · 2020/05/10(日) 11:02:41.97

C#
海外を含めるならWin鯖除外でも今やGoよりは多いんじゃないか

**デフォルトの名無しさん** · 2020/05/10(日) 11:59:28.84

>>482
訂正、サーバでバックエンドとして
C#かー

**デフォルトの名無しさん** · 2020/05/10(日) 13:04:42.48

C++

**デフォルトの名無しさん** · 2020/05/10(日) 14:28:40.79

Javaじゃね？って言葉を無視するのであれば、Scalaは聞いたことある。

**デフォルトの名無しさん** · 2020/05/10(日) 15:35:37.07

コンパイル言語で伸びそうなのはKotlin

**デフォルトの名無しさん** · 2020/05/10(日) 18:14:39.27

javaがinnullable化すればいいんだ
いつ達成されるのか

**デフォルトの名無しさん** · 2020/05/10(日) 18:21:05.86

凄いスレ違い

**デフォルトの名無しさん** · 2020/05/13(水) 07:56:28.24

Goは学習コストが少ないっていう嘘に騙されてるやつとそう信じてる信者が多いのが最大の失敗
コード読むだけじゃ見落とすような罠が簡単につくれるし直感的に分かりづらい仕様と機能不足が多すぎる
書き捨てるだけなら簡単だがチーム開発で採用するには残念すぎる言語

**デフォルトの名無しさん** · 2020/05/13(水) 08:32:08.19

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

**デフォルトの名無しさん** · 2020/05/13(水) 08:34:54.68

見えない罠が多すぎる言語よりは数段マシなんだよな

**デフォルトの名無しさん** · 2020/05/14(木) 17:27:46.77

>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった

あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった

**デフォルトの名無しさん** · 2020/05/15(金) 00:10:35.84

>>490
他と比べたら、って話でしょ

**デフォルトの名無しさん** · 2020/05/15(金) 01:28:18.31

>>493
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる

**デフォルトの名無しさん** · 2020/05/15(金) 05:05:48.78

>>495
あ、脊椎で反射的に反論しそうになったけど指摘されてみると全くその通りだね
ファクトリからインタフェースを返すのは悪手だわこれ

**デフォルトの名無しさん** · 2020/05/16(土) 11:46:57.57

1.12 の http/request.go に、でっかい落とし穴が

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

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

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 12:28:15.83

xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );

じゃダメなん？

**デフォルトの名無しさん** · 2020/05/16(土) 12:29:08.12

うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの

**デフォルトの名無しさん** · 2020/05/16(土) 12:30:20.91

>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ

**デフォルトの名無しさん** · 2020/05/16(土) 12:34:33.17

普通、ParseForm が判定して取り込むよね
なんで分離してんの？

**デフォルトの名無しさん** · 2020/05/16(土) 13:02:51.76

エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

ショボい作りだ

**デフォルトの名無しさん** · 2020/05/16(土) 13:05:20.47

request.go の中身を初めて見たけど、エラー処理は雑だし残念すぎるなコレ

**デフォルトの名無しさん** · 2020/05/16(土) 13:11:02.15

request.MultipartReader() の方を使ってみたら

**デフォルトの名無しさん** · 2020/05/16(土) 13:14:14.23

>>504
ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから

**デフォルトの名無しさん** · 2020/05/16(土) 14:52:00.85

マルチパートって、要は多段formだっけ

**デフォルトの名無しさん** · 2020/05/16(土) 14:59:51.10

なのかな？よく知らない

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

**デフォルトの名無しさん** · 2020/05/16(土) 15:12:59.98

>>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.59

>>508の補足
Content-Typeが無かったらboundaryが取得できないのにParseMultipartFormでパースしようとするからエラーを返す

**デフォルトの名無しさん** · 2020/05/16(土) 15:30:06.54

「この中にformがいっぱい入ってますよ」っていうformなんだよね

**デフォルトの名無しさん** · 2020/05/16(土) 15:43:30.65

ヘッダーのContext-Typeで分岐して適切なParseなにがしを呼べってことです。

**デフォルトの名無しさん** · 2020/05/16(土) 16:52:50.26

>>511
何のメリットがあって呼ぶ方が判定しなければならないのか、教えてください

**デフォルトの名無しさん** · 2020/05/16(土) 17:00:10.79

駄々こねてるようにしか見えんぞ

**デフォルトの名無しさん** · 2020/05/16(土) 17:24:44.07

う～ん、Context-Type が指定されていないのに multipart を自動判別して
くれるライブラリとかフレームワークって他所の言語にあったりするのかな…？

**デフォルトの名無しさん** · 2020/05/16(土) 17:34:03.50

自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている

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

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:40:18.88

505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから

**デフォルトの名無しさん** · 2020/05/16(土) 17:40:39.14

MIME Type
MIME Encoding

**デフォルトの名無しさん** · 2020/05/16(土) 17:45:07.11

それはバウンダリの中身に、
Content-disposition: attachment; filename="xxxxx"
Content-Type: text/plain
なんかが書いてあるからできる動作であって、実はバウンダリの中身はかなり自由。
マルチパートの中にさらにマルチパートを入れるマトリョーシカのようなことをしてもかまわん。仕様上は。
これをきれいに自動でデシリアライズするのは結構難しいと思うけど。
そういう意味では、呼ぶ側が解釈を与えないといかんって割り切りは間違っちゃないんじゃないか？
他のコンパイル言語でどう対応してるのか気になるな。

**デフォルトの名無しさん** · 2020/05/16(土) 17:51:34.17

仕事でAWSのAPI Gatewayって機能使った時に
マルチパートフォームデータだけは解釈してくれなかった
クラウドサービスの都合上外部のライブラリ入れるにはソースに同梱するしか無く、
それは嫌だったからバックエンドのLambda（goに対応しているけど仕事で使ったのは非go）で
自前でバウンダリのfrom-toを切り取った上でガン無視してリクエストbodyを拾うだけの処理を書いた記憶があるｗ
完全にスレチだけど

**デフォルトの名無しさん** · 2020/05/16(土) 17:54:45.69

>>515
だってContent-Typeに現れるのはその2種類だけとは限らないから全部ライブラリ任せにはできんだろ。

**デフォルトの名無しさん** · 2020/05/16(土) 17:55:54.20

ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:06:23.99

>>520
それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:13:07.38

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.81

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.02

>>523
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？

**デフォルトの名無しさん** · 2020/05/16(土) 18:35:18.02

>>525
GitHub リポジトリの develop branch から引っ張ってビルドしたもの

$ go version
go version devel +810c27e9be Wed May 13 11:59:26 2020 +0000

**デフォルトの名無しさん** · 2020/05/16(土) 18:49:32.90

あ、それ違う

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:53:01.16

つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している

**デフォルトの名無しさん** · 2020/05/16(土) 18:57:51.02

ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる

**デフォルトの名無しさん** · 2020/05/16(土) 19:07:51.23

意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう

**デフォルトの名無しさん** · 2020/05/16(土) 19:47:58.26

>>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.65

>>531
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる

**デフォルトの名無しさん** · 2020/05/16(土) 21:30:32.48

最終的に

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.08

>>532
> としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？

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

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

>>533のあなたの最終的な実装を見るとあなたはContent-TypeとParseFormとParseMultipartFormを理解して使って無いの、何となく動くからってやっつけで実装したようにしか見えないの。

**デフォルトの名無しさん** · 2020/05/17(日) 07:48:39.85

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

まぁ、頑張って。

**デフォルトの名無しさん** · 2020/05/17(日) 08:01:02.13

>>534
>>516

**デフォルトの名無しさん** · 2020/05/17(日) 08:02:56.61

> i.Json = &BindStructure{}
の部分は
i.Json = BindStructure{}
の間違えでした。

**デフォルトの名無しさん** · 2020/05/17(日) 08:07:59.87

>>535
application/json ってFormを送るブラウザがあるのか？
bodyをjsonとして送ってくるんだな

**デフォルトの名無しさん** · 2020/05/17(日) 08:10:55.71

寝ぼけてるぽい、もう一回上げ直し
>>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{})
// err = d.Decode(&i.Json)
i.Json = &BindStructure{}
err = d.Decode(i.Json)
default:
err = r.ParseForm()
}
}
return err
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:16:05.54

>>535
あ、REST-APIでよく使われる形式なのか
そういうForm使わない呼び出しはサポートしないんで割愛

POST以外のAPIアクセスは事前に拒絶してるから割愛

現状でも問題ないな(手抜き)

**デフォルトの名無しさん** · 2020/05/17(日) 08:21:16.95

>>540
いや違う
mime.ParseMultimediaTypeは呼んだ方がいい？
呼んだ方がいいから書いてくれてるんだろうな
追加しておきます
ありがとう

**デフォルトの名無しさん** · 2020/05/17(日) 08:26:21.18

スレチになるのでちょっとだけ。
ブラウザが送るって言う解釈とはちょっと違うけどjavascriptで
fetch(url, {
method: 'POST',
headers:{"Content-Type": "application/json"},
body: JSON.stringify(data)
}).then(res => res.json()).then(function(resp) {
// ...
})
みたいにapplication/jsonでリクエストできます。

**デフォルトの名無しさん** · 2020/05/17(日) 08:35:11.77

>>539
まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)
Context-Type が無かったらParseFormの出番だと思う

**デフォルトの名無しさん** · 2020/05/17(日) 08:36:58.14

>>541
> mime.ParseMultimediaTypeは呼んだ方がいい？

// ct に「;」がある場合に「;」より前を取得してるだけなので
// mime.ParseMultimediaType使わずにこれでもいい
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:38:10.44

>>542
うん、でもそこはAPIの仕様だから
汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話

**デフォルトの名無しさん** · 2020/05/17(日) 08:40:22.86

> まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)

ごめんこっちに置き換えてw
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
iphoneで書いてるからちょっと適当になりましたw

**デフォルトの名無しさん** · 2020/05/17(日) 08:45:00.28

func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
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{})
// err = d.Decode(&i.Json)
i.Json = &BindStructure{}
err = d.Decode(i.Json)
default:
err = r.ParseForm()
}
return err
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:51:07.87

現時点で

// SetParseMemory は ParseMultipartForm で指定するメモリサイズを変更します。
func (i *rInst) SetParseMemory(size int64) {
i.size = size
}

// ParseForm() error
func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if v == "" {
return i.request.ParseForm()
} else {
if pos := strings.Index(v, ";"); pos != -1 {
v = v[:pos]
}
if v == "multipart/form-data" {
return i.request.ParseMultipartForm(i.size)
} else {
return i.request.ParseForm()
}
}
}

とした

**デフォルトの名無しさん** · 2020/05/17(日) 08:54:49.63

あ、これでいいのか

// ParseForm() error
func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if pos := strings.Index(v, ";"); pos != -1 {
v = v[:pos]
}
if v == "multipart/form-data" {
return i.request.ParseMultipartForm(i.size)
} else {
return i.request.ParseForm()
}
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:55:11.84

>>545
＞うん、でもそこはAPIの仕様だから
＞汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話

わかりました。

サンプルがちょっとグダグダになってこめんなさいw
とりあえす頑張ってください。

**デフォルトの名無しさん** · 2020/05/17(日) 08:57:15.07

>>549
それでもいいです。

**デフォルトの名無しさん** · 2020/05/17(日) 09:00:02.16

結局、application/json のために ParseForm から ParseMultipartForm を追い出してる？
やっぱり自分的には納得いかない