usakdsteen

ゆうさくですてぃーん

2020年10月13日(Tue)の独り言

inwardly testing

の呟きは 44

 < の独り言 | の独り言 | の独り言 > 
  •  #

    次
    https://projecteuler.net/problem=57

  •  #

    とびとび

    f:id:neetsdkasu:20201014012110p:plainf:id:neetsdkasu:20201014012116p:plainf:id:neetsdkasu:20201014012123p:plainf:id:neetsdkasu:20201014012130p:plain
  •  #

    shower time...ですかね

  •  #

    謎バグあったけど
    同じtimelineが2回挿入されるというの
    再現しないので
    何故起きたのかわからん・・・

    •  #

      10月9日ので起きたけど
      わからん

  •  #

    バグは埋め込むもの・・・

  •  #

    暑い

  •  #

    https://stackoverflow.com/questions/28793619/golang-what-to-use-http-servefile-or-http-fileserver

    •  #

      ok

    •  (UPD ) #

      実装見る限り、そんなに違いなさそうな
      https://golang.org/src/net/http/fs.go?s=20871:20911#L710

      serveFile()を呼び出す前段階を見るなら
      http.FileServerよりhttp.ServeFileのほうが安全なような？
      http.ServeFileはドットを含むやつをエラーで返すけど
      FileServerはpath.Clean()してるくらいしかない
      path.Clean()はどう考えても危険だが？

      •  (UPD ) #

        serveFile()内で特にパスについて配慮されてないし
        http.ServeFileを使うほうが安全じゃん

      •  (UPD ) #

        https://stackoverflow.com/questions/25945538/go-golang-to-serve-a-specific-html-file
        古いバージョンだとhttp.ServeFileは安全ではなかったらしい、
        バージョン1.6移行で..を弾くようになったらしいが

        •  #

          http.FileServerを安全とする根拠がよくわからんが

          •  (UPD ) #

            わかった
            path.Clean()は
            path.Clean("../../hoge") だと"../../hoge"のままだけど
            path.Clean("/../../hoge")は"/hoge"になってルートより潜らないことが保証されると、
            んで、http.FileServerはリクエストのパスの頭に"/"をつけてpath.Clean()する処理があるから、ファイルパスが練成されるタイミングでは安全が保証されるということか

            •  (UPD ) #

              http.ServeFileはディレクトリとファイルを区別せずに取り扱うから
              serveFile()の実装ではリクエストのパスをうまく取り扱えない、と？

              •  #

                serveFile()内でr.URL.Pathを直接扱うのが悪いんじゃね・・・？

                •  #

                  いあ、わかんね・・・難しい・・・

    •  #

      ひとまず
      ディレクトリ以下を晒すならhttp.FileServerにしとくが、常套手段、か

  •  #

    https://golang.org/src/net/http/server.go?s=74967:75027#L2412

    ServeMuxは一度登録したパターンはそれが絶対になるのか・・・？

    •  (UPD ) #

      内部でLock使ってるから
      サーバー稼働中に新規でパス追加するのは大丈夫そうだけど

    •  #

      パスの有効無効を実行中に切り替えたい場合は
      これに登録するのはまずそう

  •  #

    ReadLockとWriteLockくらい使い分けたほうがいいよなあ・・・

    •  #

      今から作ろうとしてるやつは
      RW分けるのが不可能そうに感じる

      •  #

        sync.MapのLoadOrStore
        生成コストが高い場合は使えなさそう

        •  #

          http.FileServer
          内部で状態を持たないみたいだし
          毎度生成しても大差無さそう

          •  (UPD ) #

            http.StripPrefixをかますなら
            生成して保持する価値はありそう

            •  #

              動的関数のコストってどんなもんなんだろ？

              •  #

                関数本体をまるまる保持とかあったりするの？

              •  #

                クロージャって言うのか

                •  #

                  動的関数という言い方は間違いだた

    •  #

      まぁ自分でのアクセスしかないのだから
      単純なLockだけで問題は無さそうな気もするが
      同時アクセス、あるか？ないよなあ

  •  #

    おｋ

  •  #

    プログラミング、難しい

    •  #

      プログラミングを職業にするの無理ゲー
      頭のいい人向けの職業だなって感じしかしない

      •  #

        (omitted)

  •  #

    最近マジ太ってきた
    買い食い自重しないと・・・

    •  #

      買い食い自粛

    •  #

      ぶよぶよ

    •  #

      マジで腹まわりがぶよぶよしててヤバい
      買い食いやめないと・・・

    •  #

      (omitted)

    •  #

      (omitted)

  •  #

    根底
    https://neetsdkasu.hatenablog.com/entry/2020/07/21/052024

    構想
    https://neetsdkasu.hatenablog.com/entry/2020/07/30/063453

    着手開始
    https://neetsdkasu.hatenablog.com/entry/2020/07/31/043736

    •  #

      まぁ始めて3週間くらいで最低欲しい部分は実装できてたっぽいよなあ
      f:id:neetsdkasu:20201006010053p:plain

      •  #

        だらだらやってたせいで3ヶ月か・・・

        •  (UPD ) #

          真面目にこればかりをやってれば2ヶ月もかからず完成してたかもしれない

 < の独り言 | の独り言 | の独り言 >