アカウント名:
パスワード:
テストの段階でこういうの普通に踏むと思うんだけどこれくらいのテストしておかなかったのかなあ(実際当方は踏んで、ダメなユーザ名の一覧を作ってバリデーション条件とした)、とか、抑も数字だけのユーザ名は何となく避ける感覚なかったのかなあ、とか思うところはいくらかある
urlの構造の問題と同時に200以外で異常を表す正常なページを返す悪しき習慣の弊害もある。
# httpの仕様外の挙動してるんだからそれを考慮しなかったただの漏れとは言え
それについてはQiitaがNginxをちゃんと使えていない可能性もある。
named location(location @hogeみたいなやつ)や、内部にinternal; [nginx.org]を置いたlocationブロックは、外部からのアクセスでは使用されなくなり、error_pageやその他Nginx内部リダイレクトでのみ到達できるlocationになる。こうするとhttps://example.com/500 で500用ページが丸見えというのは回避できる。
Qiita運営がそれを知らないのか、より下流のリバースプロキシ・CDN等で利用するため意図して/500などを公開しているのかは、外部の人間には分からない。
なお、QiitaがNginx使っているのは、HTTPレスポンスヘッダーフィールドのServerを見てそう判断した。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
昔似たようなURL設計のSNS作ったことがあった (スコア:2)
テストの段階でこういうの普通に踏むと思うんだけどこれくらいのテストしておかなかったのかなあ(実際当方は踏んで、ダメなユーザ名の一覧を作ってバリデーション条件とした)、とか、抑も数字だけのユーザ名は何となく避ける感覚なかったのかなあ、とか思うところはいくらかある
Re:昔似たようなURL設計のSNS作ったことがあった (スコア:0)
urlの構造の問題と同時に200以外で異常を表す正常なページを返す悪しき習慣の弊害もある。
# httpの仕様外の挙動してるんだからそれを考慮しなかったただの漏れとは言え
Re: (スコア:0)
それについてはQiitaがNginxをちゃんと使えていない可能性もある。
named location(location @hogeみたいなやつ)や、内部にinternal; [nginx.org]を置いたlocationブロックは、外部からのアクセスでは使用されなくなり、error_pageやその他Nginx内部リダイレクトでのみ到達できるlocationになる。こうするとhttps://example.com/500 で500用ページが丸見えというのは回避できる。
Qiita運営がそれを知らないのか、より下流のリバースプロキシ・CDN等で利用するため意図して/500などを公開しているのかは、外部の人間には分からない。
なお、QiitaがNginx使っているのは、HTTPレスポンスヘッダーフィールドのServerを見てそう判断した。