+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/03/22(日) 16:19:45.75

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

+ JavaScript の質問用スレッド vol.123 +
http://peace.2ch.net/test/read.cgi/hp/1423915644/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2018/02/15(木) 15:43:52.20

ひとまず
https://stackoverflow.com/questions/37334220/how-do-i-return-a-http-404-status-code-from-a-spa
上記リンクの情報に従うと
404 page にリダイレクトさせることでステータスコードを返すって方法しかない
ということでいいでしょうか？

js側でステータスコードを返したようにブラウザに認識させる方法とか
あるのかなーと期待していたんですが、、、

**デフォルトの名無しさん** · 2018/02/15(木) 15:55:44.81

俺としてはまあ答はでてるんだが
ほかの人、もう少し頑張ってみてくれｗ

**デフォルトの名無しさん** · 2018/02/15(木) 16:33:58.37

どうせSEOのために仕方なくでしょ。
ソフト404でいいと思うんだがSPA推してるくせにgoogleマジなにやってんの。

**デフォルトの名無しさん** · 2018/02/15(木) 17:23:29.73

サーバー側のCGIが404を返すことは何の問題もない
PATH_INFOで動作しているCGIは404や300番台も返すことがある
例えば、 ttps://www.amazon.co.jp/dp/abcdefg
ブラウザ内部では200と404を区別してるだろうけど、見た目には200と404の違いはない

404を返す方法じゃなくて、返ってきた404コードをどのように扱うかは
SPAに限ったことではなく、Ajax全般に言えることだが
フレームワークはフレームワークにその書き方が用意されてなかったらどうにもならんだろ

生のJavascriptの場合

if( xhr.status === 200 ){

}else if( xhr.status === 404 ){
//たとえばalert()して終わり
//responseTextやあらかじめ用意しておいたエラーページを表示してpushState()
//locationでそのURLに移動する
}

自分はlocationで移動する方法はあまりいい方法とは思えんけどな

**デフォルトの名無しさん** · 2018/02/15(木) 18:15:02.91

SPAでも、ルーターで判定するだけじゃないの？
俺はそうしてるけど。
SPAなんだから、誰がどうその404と言う情報が欲しいかというと、多分エンドユーザだよ。
となると、ごく当たり前のように404に相当するコンポーネントを出すしか出来ないだろ。
それが正しく404として扱われてるか、はGoogle Search Consoleで確か確認できる。
むしろ404として扱われていないかを確認するためにも、Search Consoleは見るべきかと。

**デフォルトの名無しさん** · 2018/02/15(木) 19:02:16.42

>>864 に書いた
> //たとえばalert()して終わり
> //responseTextやあらかじめ用意しておいたエラーページを表示してpushState()
> //locationでそのURLに移動する
この部分の書き方にどんな種類があるのかを知りたいのではなく、
サーバーは404を返したけど、クライアント（フレームワーク・ルーター）が反応しないということであれば
フレームワーク・ルーターには
if( xhr.status === 200 ){
}
これしか書かれてないわけだから、
あきらめて200で処理する（いわゆるソフト404）か、フレームワーク・ルーターを作り直せという返事になる

**デフォルトの名無しさん** · 2018/02/15(木) 19:49:37.33

>>864
返ってきたコードをどう扱うかは自由だが
locationで移動しない場合、検索エンジンなどに404を伝えるにはどうするんだよ

**デフォルトの名無しさん** · 2018/02/15(木) 19:53:50.40

>>866
サーバが返すも何も、SPAで、fetchのレスポンスがなんて話なら、そりゃアプリケーション内部の話であってユーザには全く関係が無いかと。
そんな台所事情でエラーメッセージを出すのは404でもなんでもなく、デスクトップアプリで予期できるexceptionを吐いたときにexceptionをそのまま出力しちゃうぐらい悪手では？
かつ、少なくとも、その場合はサーバ側のロジックも結果なしという結果、にすべきなんじゃないかな。
本当にそのリソース(API)がデグレなりクライアントのキャッシュなりでバージョン不一致なりの理由で存在しない場合との切り分けが難しくなる。
RESTのAPIだから、なんて場合は404を返したいのはわかるんだけど、危険な原理主義ではないかなぁ。

**デフォルトの名無しさん** · 2018/02/15(木) 20:57:04.69

>>867
HTTPヘッダの404を見て404で登録される
https://support.google.com/webmasters/answer/35120?hl=ja
URLエラーのタイプ、一般的なURLエラーのソフト404の説明書きを参考

ただ、フレームワークが200しかサポートしていない、にもかかわらず404で処理したい
というのであれば、まあ、locationしかないんじゃないかなと思うんだけど
検索エンジンに、SPAのURLとlocationでジャンプしたURLが同一だということを理解できるのかなぁ

>>868
ブログにニュース記事へのリンクを張った後に、
ニュース記事を削除した場合に404を返すようにしている
Google SEO的には410のほうがいいかもしれないけど

ページを追加、削除し、そこにリンクを張った過去のブログを更新しないことなんかはよくあることだし、制作時に対応できない

検索結果０件（コンテンツのない、またはSEOの重要度が非常に低いURLが存在する）のと、
URLそのものが存在しないのとは区別すべきというのが自分の考え方だから

**デフォルトの名無しさん** · 2018/02/15(木) 21:03:46.64

どんなURLでも同じページをサーバーが返して
そのページがデータをフェッチして表示するようなもので
クローラからのアクセスの時のみ404レスポンスを返すのはありなのか?
Googleは特別扱いするなとか言いつつ、クローラを考慮した仕様も出してるから
どうしたらいいのか難しい

**デフォルトの名無しさん** · 2018/02/15(木) 21:05:43.22

つまり検索エンジンに載せたくないという理由で
実際ページが表示できるかに関わらず404を返していいのかということ
SPA用のスマートな方法は用意されているのだろうか

**デフォルトの名無しさん** · 2018/02/16(金) 09:40:25.43

>>869
自分が言いたいのはURLを動的に解釈している場合は多かれ少なかれ
URLはコンテンツの静的な住所という大原則からは外れてしまっているということ
つまり「URLそのものが存在しない」という判定が自明でなくなる

**デフォルトの名無しさん** · 2018/02/16(金) 10:54:49.83

さて、むそろそろ俺の登場かな？
この問題はねSPAだからといってパフォーマンスさげないよね？
無駄なことはしないよね？という話で解決するんだよ。

例えば、http://example.com/foo/1 とかにアクセスした時、
index.html に30x のリダイレクトしたりはしない
なぜかって？リダイレクトしたらパフォーマンス落ちるでしょ？

つまりね。PATH_INFO（でいいかな？）の情報を持った状態で
サーバーサイドアプリが呼び出されるんだよ
そこでサーバーサイド側の仕組みを使って404を返せばいい

SPAの話なのに何を言ってるのと思うかもしれないけど、
ちゃんとしたSPAっていうのはF5を押しても同じ画面が表示されるし
URLも http://example.com/foo/1 のままになるもの

SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
それは他のページから辿った場合で、直接 http://example.com/foo/1 に
アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
なぜかって？ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
データが見つからない時に404を返すことも容易

そして検索エンジンとかは、基本的にAjaxを使ってデータを読んだりしない。
読むことも有るかもしれないけど、Ajaxリクエスト（Content-Type: application/json）として
そのページを読み込むことはないだろう。だからいま問題にしているどうやって404を返すか？という
話は実は当てはまらない。検索エンジンは http://example.com/foo/1 を直接読み込むのだから

Ajaxによるリクエスト、つまり別ページを読み込んでからSPAの処理としてページを読み込む場合は
そのリクエストを404にすればよい。たしかにページ自体は404にはならないんだけどね。
でも検索エンジンには関係ない話

**デフォルトの名無しさん** · 2018/02/16(金) 11:13:52.52

>>873
今現在はサーバサイドレンダリングは不要で、GoogleBotはちゃんとjsを解釈してくれます。
但しchrome41相当なんでES2015はダメでES5にトランスパイル必須ですが。

**デフォルトの名無しさん** · 2018/02/16(金) 12:12:33.62

> GoogleBotはちゃんとjsを解釈してくれます。

なにを解釈しているかちゃんと分かってますか？

解釈していると主張しているだけで、何をどう解釈しているかは
非公開のはずですが？どうして問題ないと信じられるのでしょうか？

**デフォルトの名無しさん** · 2018/02/16(金) 12:31:37.30

>>875
https://qiita.com/m0a/items/89aec890f98a599846ce
GoogleBotのchrome version調べることができます。
bot用にカスタマイズしている可能性はあるので確かに100%保証というわけではないですが

**デフォルトの名無しさん** · 2018/02/16(金) 12:34:28.83

>>876
それで今はサーバーサイドレンダリングの話なんですか？
404にサーバーサイドレンダリングなんか関係ないでしょ

**デフォルトの名無しさん** · 2018/02/16(金) 12:37:37.23

>>877
>SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
>それは他のページから辿った場合で、直接 http://example.com/foo/1 に
>アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
>なぜかって？ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
>だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
>最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
>データが見つからない時に404を返すことも容易

ここに対するツッコミをしただけですよ。

**デフォルトの名無しさん** · 2018/02/16(金) 12:49:30.63

>>873
それはSSRする場合というごく少数のSPAの場合であって、
大体はpathinfo効かせて、htmlにリダイレクトさせると思うんだが。
悪手よ。二種類のルーターの同時保守は。

hoge/foo/1は、hogeへの/foo/1というルートのパラメータであって、パスじゃない。pathinfoの時もね。
ajaxでURLとしてのfoo/1を取得するかどうかも、SPA次第であって、実はそんなこと関係なくクライアントサイドの処理で済むものなのかもしれない。

なので、404というステータスはhtmlに対してはユーザが見れうるが、各パスに対しては見ようがない。
SPAのAはApplicationのAだからね。

**デフォルトの名無しさん** · 2018/02/16(金) 12:54:41.12

>>878
突っ込みになってないよ？
パフォーマンスの点から、最初から表示に必要なデータを
HTMLに埋め込むって言ってるんだから

**デフォルトの名無しさん** · 2018/02/16(金) 12:57:19.71

pathinfo？
pathnameのこと？

ApplicationのAだから？
railsやexpressやspringでサーバーサイドで作ったものはApplicationではない？？？

**デフォルトの名無しさん** · 2018/02/16(金) 13:01:32.14

>>879
> 悪手よ。二種類のルーターの同時保守は。

そんなもんする必要が無いだろ？

http://example.com/foo/1 にアクセスしたら
どうせクライアントサイドから /api/foo/1とか呼び出すんだろ？

ならその呼び出す命令の代わりに、
サーバーサイド側で http://example.com/foo/1 でアクセスした時に
同じ /api/foo/1 を呼び出せばいいだけ

汎用化できるから保守の必要はない

**デフォルトの名無しさん** · 2018/02/16(金) 13:04:20.87

/api/foo/1と書いたけど、もちろん /foo/1 でもよい。

その場合、Ajax（Content-Type: application/json）からのリクエストか
どうか判別してそのページのデータのみを返すか、
HTMLを返すか切り分ければいい

**デフォルトの名無しさん** · 2018/02/16(金) 13:10:38.43

そもそもGETはキャッシュラブルだとかそういうのも守れてないし

**デフォルトの名無しさん** · 2018/02/16(金) 13:12:18.28

また関係ない話が出てきたな・・・

**デフォルトの名無しさん** · 2018/02/16(金) 14:18:34.93

>>882
しないこともあるのがSPAだよ。

**デフォルトの名無しさん** · 2018/02/16(金) 16:23:26.06

しないならしなければいいだけだろ？
何を言いたいのか分からん

**デフォルトの名無しさん** · 2018/02/16(金) 17:56:44.52

>>887
だから、>>882の通りにはいかないでしょ。
リクエストのURIと同じURIのリソースを呼び出すこともあれば呼び出さないこともあるSPAだと。
アプリケーションのなかで一意なURIと、Webサーバとして配信してるURIは混同するほうがおかしい話で。
クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。

**デフォルトの名無しさん** · 2018/02/16(金) 18:24:29.38

>>888
> リクエストのURIと同じURIのリソースを呼び出すこともあれば呼び出さないこともあるSPAだと。

それはページ内部の話だろ。クローラーからすりゃ関係ない話

クローラーが記録するのはブラウザのアドレスバーに表示される
あのURLのみと考えればいい。そのURLに対してGETリクエストを行うだけ

そもそもお前、SPAの初期ページの読み込みが遅いって問題と解決方法知ってるか？

https://qiita.com/takeshy/items/b7e1b6bd30d12ecb02c6
> 1.データを別々にAjaxで取得
> 各CollectionやModelがRESTを使ってデータをAjaxで取得するので、
> リクエスト数が多くて遅くなる上に、ブラウザの同じサイトに対しての同時リクエスト数制限にひっかかります。

> 1.に関しては、初期画面のHTMLにAjaxで取得予定のデータを予め埋め込んでしまい、
> 初期データとして使うことで初期画面表示時のAjax呼び出しをなくしました。

https://qiita.com/takeshy/items/ba8b3ee4606993c1c5b8

> 初期表示時にサーバとの通信を極力行わない
> SPAで作成する場合、各モデルごとにサーバとデータを同期する必要がありますが、
> データを初期のHTMLにJSONデータとして埋め込んでしまうことで、Ajax通信を回避することが可能です。

どうせこれやるんだから、この時にデータが見つからなければ404を返すだけの話だろ

**デフォルトの名無しさん** · 2018/02/16(金) 18:31:57.24

>>888
> クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
> クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。

クライアントサイドだけが生成されるものというのはURLを持たないってことか？
URLを持たないページならクローラーの対象とならないんだから
そんなのどうでもいいだろ。URLがなｂ｢ならクローラ＝[はこねーよｗ

まさかURLを持たなくてもクロールしてくれるとか思ってねーよな？
クローラーがクリックイベントまでシミュレートして、URLは変わらないのに
ページ辿ってくれるとか思ってねーよな？しねーからなそんなこと

> https://www.bricoleur.co.jp/blog/archives/2628
> 原文：
> We don’t “click” during rendering so any click event will be ignored,
> but we do execute JavaScript that is triggered by for example onLoad events.
> > 原文：
> （Googlebotは）ページをレンダリングする際に何も「クリック」しない。
> 従って、クリックイベント（によって発生する動的なコンテンツ）は無視する。
> しかし、onLoadイベントなどがトリガーとなるようなJavaScriptについては実行する。

クローラーの動きとしては
1. ページを読み込んでレンダリングする
2. そのページのURLをかき集める
3. そのページは一旦閉じSPAが終了されてるのと同じ状態から、かき集めたURLの一つを読み込む

だからな。SPAアプリをクローラーが操作してくれるわけじゃない。
SPAの画面をそのままクロールしてくれるんじゃなくて、その状態からF5（画面更新）を
押して表示されたものしか見てくれないからな。だからURLがあることは必須

**デフォルトの名無しさん** · 2018/02/16(金) 18:54:05.52

数年前からクリックするようになってるよ

**デフォルトの名無しさん** · 2018/02/16(金) 19:30:14.75

>>891
React-router-dom触ってると
onclickで遷移する仕組みがチュートリアルで紹介されてないんだよね。
(よく探すとあるけど。)

GoogleBotが辿ってくれるためにはAnchorである必要があるってことで
そのためにonClickじゃなくてLinkタグを使って遷移処理するようにするってことだね。
非同期通信を介してレンダリングすると一々Stateに保存してLinkタグを書くのがシンドいと思ってたんだけどSEOのためだったんだなぁ

**デフォルトの名無しさん** · 2018/02/16(金) 19:33:28.56

なってるといいよねｗ

どちらにしろURLがないコンテンツは
クロールしてくれないことに変わりないんだがな

**デフォルトの名無しさん** · 2018/02/16(金) 19:36:08.89

>>892
リンクタグを使った所で、そのリンクを
アドレスバーに入れて表示されないと意味ないからね

クローラーはリンクのみを取り出してアドレスバーに入れて
表示されたものを、そのURLのコンテンツとして認識する

そこからクリックして変化したものまでクロールしてくれない
（普通に考えれば当たり前だが）

**デフォルトの名無しさん** · 2018/02/16(金) 19:45:34.13

クリックじゃなく遅延して表示してるのはどうなるんだろ？何秒か適当にwaitしてから取ってんのかな？それとも

**デフォルトの名無しさん** · 2018/02/16(金) 19:54:10.08

>>895
運次第だろ？

1秒毎に変わるページでも作って、それがクロールされるかとか
やってみたら？少なくとも全部クロールされることはないだろうね

クリックされると副作用が現れるということで、
ページ上にクリックできるものが複数あって、
じゃあどれをクリックしたものをクロールされるのか？とかさ
考えてみれば不可能だってわかると思うんだが

クローラーがJavaScriptを実行するというのは
JavaScriptで動的に出したもの全てをクロールして
くれるわけじゃないことはわかるでしょ？

クロールされるのは指定したURLを表示して（JavaScriptで）
レンダリングした最初の画面ぐらいに思っておいたほうが良いよ
そこからのonclickは動かないとみなした方がいい
もちろんレンダリングした結果に含まれるリンクにはURLが書いてあるので
新たなクロール対象になる。
onclickの場合はURLが書いてないのでクロール対象にならない

**デフォルトの名無しさん** · 2018/02/16(金) 20:46:06.30

onclickにlocation.href='hoge/fuga.html'とか書いてあったらどうなんの？

**デフォルトの名無しさん** · 2018/02/16(金) 23:15:43.67

結局404はどう解決するんだよ

**デフォルトの名無しさん** · 2018/02/16(金) 23:25:00.48

とりあえず、404って書いた画面表示しときゃいいだろ。
それで不満だって言うのなら何が気に入らないのかちゃんと挙げて議論。

**デフォルトの名無しさん** · 2018/02/16(金) 23:57:21.24

>>898
あるURLに対してクローラーがアクセスしてくる場合には
サーバーサイド側で404を表示できる。

なぜならサーバーサイド側でそのリクエストを処理するから
その時にデータがなければ404を返せる

Ajaxを使ってアクセスする場合は、そのリクエストで404を返せばいい

**デフォルトの名無しさん** · 2018/02/17(土) 00:03:35.35

何を怒り狂ってるかわからんが、クローラがちゃんとクロールしてるかどうかの調べ方は書いただろう。

>>889
ページ内部の話だから、むしろ関係ないんだよ。
SPAなんだから。
ウェブページ豪華版みたいな扱いされても困るわ。
SPAが重いって問題とは別問題。

>>890
URLじゃなくてURIとしては持つだろうね。
持つって言ってるでしょ。
それはユーザにとっての識別子であって、クローラに対してどうするかは、クローラがクライアントとなってどうするかによる。
その調べ方は書いた。

なんか大きめの勘違いしてない？
SPAはwebページとは限らないよ。

**デフォルトの名無しさん** · 2018/02/17(土) 00:06:15.35

ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。
そのURIの情報をDOMごと貰えばいい話になる。
どこのClassicASPのUpdatePanelの話なのかわからんレベルで無能じゃん。
アプリケーションだよ。

**デフォルトの名無しさん** · 2018/02/17(土) 00:49:10.87

> ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。

あ、なるほどｗｗｗｗｗ

そううかお前、サーバーサイドでレンダリングするって思っちゃってるんだｗｗｗｗ
SPA初心者だな。

クライアントでレンダリングするのに必要なデータをJSONでHTMLで埋め込むんだよ
そしてクライアントサイドでレンダリングするんだよ。
>>889のリンク先にもそう書いてあんだろ

で、クライアントでレンダリングするためのデータがなかったら、
404を返すだけの話だよ。

**デフォルトの名無しさん** · 2018/02/17(土) 00:49:44.01

>>901
> SPAはwebページとは限らないよ。

え？なに？お前のSPAはF5押したら
初期画面に戻っちゃうの？
使いづれぇなぁｗ

**デフォルトの名無しさん** · 2018/02/17(土) 02:40:20.72

F5押しても戻らないよ。
ルーターが処理してるから。

お前アホなんだろ。

**デフォルトの名無しさん** · 2018/02/17(土) 02:48:01.65

そもそも、pathinfo使ってリダイレクトさせるのは別に動的なphpやサーブレットなんかだけが対象じゃなくて、htmlでも良いんだよ。
そのhtmlはサーバから取らなくてもサービスワーカーなりなんなりでブラウザ内で処理しちゃえるから、トラフィックは発生しない。
ブラウザ内でindexedDBなり使って復帰すればそれでいいんだから、同じURIにリクエスト投げる必要もなく、ブラウザ外に問い合わせて表示データを取る必要もない。

アプリケーションなの。APIが返す値を表示するだけのブラウザじゃないのよ。SPAと言うのは。

**デフォルトの名無しさん** · 2018/02/17(土) 03:26:51.10

>>905
F5押しても戻らないってことはURLがあるってことじゃねーかｗ

**デフォルトの名無しさん** · 2018/02/17(土) 11:50:05.04

>>907
URIはあるけど、それがサーバのURLと一致してるわけじゃないよ。
理解してなくない？

**デフォルトの名無しさん** · 2018/02/17(土) 12:10:00.79

F5で完全に戻らないとしてもURLだけで
そのアプリケーションの全ての値が復元できるとも限らない

**デフォルトの名無しさん** · 2018/02/17(土) 13:29:52.85

それはURIだけで、サーバがすべての値を返すとは限らない、と同じ意味だよね。

**デフォルトの名無しさん** · 2018/02/17(土) 13:39:20.93

クローラーはURIだけでアクセスしてくるので
URIから読み取れないデータはクロールされません。

またGoogleの検索結果にSPAのJSONが
クロールされた形跡は見られませんね。
もしそのJSONがクロールされていれば
検索結果に出るはずですから

**デフォルトの名無しさん** · 2018/02/17(土) 14:18:23.54

その理屈は正しくない
もしJSONも認識できて人並みの知能があった場合
それを検索結果に出さないという判断をすべきだから

**デフォルトの名無しさん** · 2018/02/17(土) 14:22:19.46

検索結果にださなくすると
どういう効果があるの？

**デフォルトの名無しさん** · 2018/02/17(土) 14:54:23.92

SPAのJSONという時点でダム端みたいな使い方しかして無いとわかってしまう悲しさがあるな。
ブラウザは単なるレイアウトエンジンじゃないぞw

うちのログにはSPAだけがルーティングしてるアドレスに向かってのクエリはあるから、逆にajaxしてるからクローラにそこで諦められてんじゃないの？

**デフォルトの名無しさん** · 2018/02/17(土) 17:47:46.20

よくよくこいつがなんで馬鹿な事言ってるか考えてみたんだが、URIだけでアクセスしてくるが、その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリングできてしまうがある事を想定してないんだろうな。
URIで指定されたコードをバーコードとして画面に表示するとか色々作ったが、そう言うのは多分想定外なのかなと思ったわ。

HTTPとしてGETするリソースと、ブラウザにあるコンテンツを求めるために示されるURIはイコールじゃない。
だからHTTPサーバはindex.html/jsに相当する内容をいつでも同じように返すし、サービスワーカーが動いてればそのサーバへの問い合わせすらしない。
いつでも、そのhtmlやjsが、自身に与えられたURIから、コンテンツを作る。

**デフォルトの名無しさん** · 2018/02/17(土) 18:17:07.03

>>901
この文脈であえてURLとURIを区別する意味が分からん。

**デフォルトの名無しさん** · 2018/02/17(土) 18:27:57.81

>>915
いや、そうじゃなくて
「その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリング」
という処理をするためには、

1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする

の3～4のサーバーへのリクエストの処理について考察できてないんでしょ？

そしてSPAでは2回サーバーにリクエストを投げるのが当たり前で解決できない問題だと思い込んじゃってる。
まともなSPAだとここを1回にする。理由は2回リクエストを投げるとパフォーマンスが落ちるから。

2回サーバーにリクエストを投げる方法だと2の時点で200が返ってきてしまい、4の時点で404を返すことになるが、
リクエストを1回にした場合は、2の段階でindex.html/js相当＋画面と内容を表示するためのデータを貰うことになるので
この時点で404を返すことができる。

**デフォルトの名無しさん** · 2018/02/17(土) 20:48:04.60

>>917
違うよ。3は、必ずしも存在しないって言ってるの。
SPAでは2回リクエストを送ることもあるだろうし、リクエストを送らない事もあるって言ってるの。
まともなアプリケーションでは、一回も送らなくて済むならば送らない。
htmlやjsをサービスワーカーでキャッシュしてれば、そもそももっと話が変わってくる。
(特定のURI以下へのリクエストをサービスワーカーでキャッシュから解決するだけ)
さらに、URIの中身で画面が作れる場合、アプリケーションから見てそれは本当に唯一無二のURIだよ。Locatorではなく、Identifier。

お前は、最低一回リクエストするはずだ、という思い込みというか、それ以外の方法を知らないんだと思うよ。
要はウェブページプラスαの考え方。

**デフォルトの名無しさん** · 2018/02/18(日) 02:19:09.25

>>918
今、話をしてるのはクローラーの話だって分かってない？

クローラーはクッキーやローカルストレージは使わない
https://www.suzukikenichi.com/blog/googlebot-uses-a-web-rendering-service-that-is-based-on-chrome-41/
ページレンダリング中に一時的に使ってるかもしれないが読み込み時に毎回クリアされる

クローラーっていうのは、HTMLを取得（ページをレンダリング）する処理と、URLをかき集める処理が別れている
そしてクローラーは自分が知ってるURLに対してGETリクエストを送る
だから一回もリクエストを送らないということはありえないんだよ。

クローラーはブラウザじゃない。ブラウザのように前の状態というのを持たない。
だからアプリの作りが例えサーバーと通信しない作りであっても
知ってるURLに対して初回アクセスと同じようにかならずGETリクエストを送ってくる
そしてクッキーやローカルストレージは持たない

クローラーは必ずSPAのアプリケーションの特定のURLに対して直接GETでアクセスしてきており
（アクセスしない＝最新の情報がわからないのだからクロールされてるページ内容の更新を行わない）
なおかつ初回アクセスと同じようにデータは空なのだから、状態は200か404のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）

クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？それなにもクロールしてないからｗクローラーの使命を果たしていない

**デフォルトの名無しさん** · 2018/02/18(日) 11:26:35.43

それって今のGoogle Botの話でしょ？
クローラが一般的にそうである必要はないよ
Google Botも重要なサイトでは高機能長時間のクロールをしてるって噂もあるし

**デフォルトの名無しさん** · 2018/02/18(日) 11:51:48.11

SEOの話ならあっちでやってくれ

**デフォルトの名無しさん** · 2018/02/18(日) 11:53:05.84

クソみたいな長文で自分の理解が及んでませんでしたって言い訳されても困るわ。
それも織り込んで話してる。

**デフォルトの名無しさん** · 2018/02/18(日) 13:52:18.73

>>920
長時間クロールっていうのはたくさんのページを
まとめてクロールしてるってだけ。動きは変わらない。

> クローラが一般的にそうである必要はないよ
個人的にしか使わないクローラーは別として
一般的なクローラーは、不特定の人が見るわけだから
このような動きになる。

**デフォルトの名無しさん** · 2018/02/18(日) 13:52:56.22

>>922
なんかいえやｗ

**デフォルトの名無しさん** · 2018/02/18(日) 13:55:42.29

要はURIだけで画面が作れる画面ってのはあるんだよ。
URIがデータの時な。
クライアントサイドだけで(JSで処理される)リンクをたどる、のはやってくれてるよ。
リファラ見るとわかる。
そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。

ajax！json！ブラウザに上のURLと同じURLでAPIがjsonを返すんだ！と狂って叫ぶ前に、ちゃんと理解すれば良いのに。
ブラウザ上のURLと同じURLで実はJSONを返してる、とか、逆にクローラは無視しにかかるだろ。
クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
SPAなんにもわかってねえな。

**デフォルトの名無しさん** · 2018/02/18(日) 13:59:45.98

>>921
SEOの話とは違うね。
ページが見つからない時、どうやって404を返すべきかどうかの話

SPAがどうたらとか、サーバーにアクセスしないときがどうとか
言っているが、それらは全く関係ないってことを言ってる。

普通にサーバーにアクセスされた時にデータがなければ404を返せばいい
どんなページもURIを持っていればサーバーにアクセスされうる
（その典型的な例がクローラーってだけの話）

サーバーにアクセスしないときは～なんて考える必要はない。
そもそもアクセスされないなら何も出しようがないだろ？

**デフォルトの名無しさん** · 2018/02/18(日) 14:07:51.73

>>925
> 要はURIだけで画面が作れる画面ってのはあるんだよ。
> URIがデータの時な。

URIがデータだったとしても、（そもそも全てのURIがそうなんだがｗ）
話は関係ない。

URIを持っていればサーバーにアクセスされうる
SPAの場合にサーバーにアクセスしない場合もあるってだけで

ブラウザでF5を押したりクローラーからアクセスされる。
だから必ずしも作る必要はないが、ちゃんと作るならば
サーバー側の処理は必要。その時にデータがなければ404を返せばいい
（URIの情報しか使わないというのならそれは200だろうけどな）

> クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
> SPAなんにもわかってねえな。

そもそもレンダリングする前に、クローラーはSPAであることもわすれて
URIに対してサーバーにアクセスする。ここでSPAのことを考えること自体が意味ないんだよ

ちゃんと作るならば、サーバーにアクセスされた時に必要なデータがなければ404を返せばいいだけ
データの有無の話でAjaxによるアクセスかどうかとかの違いも考える必要はない。
どんな内容を返すか？のために考えるのであって、データがないときは404

**デフォルトの名無しさん** · 2018/02/18(日) 14:17:14.66

>>927
だから、サーバにアクセスされても、indexと同じものを返すよ。サーバからのリソースは。
F5を押されたって同じだ。

そのURIにデータがあるか無いかは、クライアント次第なんだから、サーバが返すのは不可能。
もちろんデータのうち、ユーザが作るようなもの、クローラがそもそも「生成しようがない」ものは拾えなくて当然というか、
クローラには一生生成できないURIで表現されるので、検索結果には上がらんし、そういうデータの一覧画面は空として上がるだろう。上がらないようにしたけど。

ただ、アプリケーションだけがハンドリングする静的なコンテンツ、はクローラが拾う。
それはサーバリソースと全く関係なく、jsにバンドルした内容から描画してる画面なんかも含まれるわな。
OSSのライセンス一覧とロゴのaboutなんかとか、特定のコンポーネントだったり、色々あるだろうが。

お前が言ってるSPAはアプリケーションと言うより、ブラウザのレンダリング力を借りたダム端なんだろう。
ダム端知らないなら早めに言ってね。言い換えるから。

**デフォルトの名無しさん** · 2018/02/18(日) 14:20:48.05

>>925
> そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。

そういう話はしてないんだなぁｗ

SPAでページがない時に404を返したい。どうすればいいか。という話

答は、今までと何も変わらない。
サーバーにアクセスした時にページを表示するために
必要なデータがなければ404を返せばいい

反論としてSPAだとサーバーにアクセスされない場合が～とかいうから
どのページでもURIを持っていれば、サーバーにアクセスされる可能性があります。
特にクローラーは必ずサーバーにアクセスしてきます。
その時に404を返せば良いのです。という話

**デフォルトの名無しさん** · 2018/02/18(日) 14:25:32.86

>>928
お前、前提がおかしいぞ？

今は、サーバーにデータが無い場合に404を返すにはどうするかの話だ
そもそもHTTPステータスはサーバーが返すもの。サーバーでしか判断できない

ダム端も全く関係ない話。クライアントの端末がなにであるかとか
クライアントがブラウザとかクローラーとか、SPAか否かとか
そういったクライアントは完全に無視できる話なんだよ。

お前が言いたいのはクライアントが○○の場合には～と
全部クライアントの話ししかしてね～じゃんか
クライアントは関係ないんだよ。忘れていい。

**デフォルトの名無しさん** · 2018/02/18(日) 14:30:39.49

クライアントが関係ないっていうのはクローラーの例を使っても説明できる。

つまり、あなたのクライアントと、私（クローラー）のクライアントはデータを共有していません。

あなたのクライアントでは何かデータが表示されるんでしょうが、
私（クローラー）のクライアントはあなたのデータなんか知りません。

あなたのクライアントでSPAが動いていようが
私（クローラー）のクライアントでは動いていません
ってことなんだよ

**デフォルトの名無しさん** · 2018/02/18(日) 14:42:23.81

クローラーが高度なレンダリング機能を備えているから
JavaScriptが動くっていうのも、クライアントの話なんで関係ない
単にレンダリングするってだけ

ここでSPAが～とか言ってくるやつは、
レンダリングされる＝SPAとしてクローラーが動くって
考えちゃってるんだろうなって思う。

もう少し具体的にいうと

クローラーが、Aというページを読み込んで表示されたBというリンクをクリックして
（History APIでURIが変わった時に）A+Bとなった情報を保存する
と思い込んじゃってるんでしょう？

そういうクローラーを作ることは可能だが、そんなことはしない。
なぜなら、Bというリンクをクリックした時にサーバーにアクセスしないかもしれないから
それを許すとクローラーのマシンの中だけで無限にアドレスが作れる。
しかもそのアドレスは他人がアクセスできるとは限らない。
クローラーというクライアントが生成したクローラー専用のURIになる。

実際の動きはこう
クローラーが、Aというページを読み込んで表示されたBというリンクを巡回するURIとして記録する
別のタイミングでHistoryAPIなんか使わずにBというURIでサーバーにアクセスして表示されたものを保存する

で、ここで重要なのはクローラーの "例から" 分かる通り URIを持つならばサーバーにアクセスする可能性がある
サーバーにアクセスされた時に404を返せば良いんだよっていう話をしている。

**デフォルトの名無しさん** · 2018/02/18(日) 14:42:58.66

>>929
だから、結論を言うと、SPAで404にあたる場合に、表示するかなんてサーバが関与する事ではない。
ルータの二重管理にもなる。

だから、SPAでソフト404を出すしかない。

って言ってるんだが。

**デフォルトの名無しさん** · 2018/02/18(日) 14:44:45.48

>>931
>>932
その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。
お前は2010年あたりから進化してないのかよ。

あと、クローラのクライアントでもレンダリングされてるよ。
確認してこいよw

**デフォルトの名無しさん** · 2018/02/18(日) 14:45:15.29

>>932
違うよ。

**デフォルトの名無しさん** · 2018/02/18(日) 14:48:58.99

>>933
だからSPAなんて忘れろってｗ

SPAを使おうが使うまいが、サーバーにアクセスされる時に
データがなければ、サーバーが404を返せばいいだけだって言ってる。

URIを直接ブラウザで開くならば、そのタイミングで404を返せばいいし、
History APIでURIを変えただけならば、その時にAjaxでリクエストあればそのタイミングで404を返せばいい
（その時にAjaxでリクエストがなければそもそも404を変えしようがない）

404をどう返すかの話をしていて、404をどう表示するかの話はしてないんだよ。

**デフォルトの名無しさん** · 2018/02/18(日) 14:49:05.24

サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。
だから頭おかしい発想になってるんだと思うが。
404である、とか、一旦Webページの発想から離れられないもんか、
Dreamweaverでシコシコ画面作ってる「ウェブ屋」でもあるまいし。

**デフォルトの名無しさん** · 2018/02/18(日) 14:51:07.76

>>934
> その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。

https://www.nttpc.co.jp/yougo/%E3%83%80%E3%83%A0%E7%AB%AF%E6%9C%AB.html

>　つまりダム端末は、自分で計算したりデータを保存したり出来ない“頭の悪い端末”という意味で、
>英語では dumb-terminal（ダム・ターミナル）という。それを日本語化して
>「ダム端末」、略して「ダム端」と呼ぶことも多い。

レンダリングする頭があればダム端にはならんが？w

**デフォルトの名無しさん** · 2018/02/18(日) 14:53:33.03

>>936
なんで忘れなければいけないんだ…？
>>834
が発端だろ。

URLをブラウザで叩いて、404であるかどうかって時点で違うよね。
ajaxがどうのと言ってるけど、ajaxなんか発生しない、単なる画面切り替えのhistoryAPI操作もあるよね。
それは、もとの画面が切り替わった状態、として扱われるべきだよね。リロードの時。
でも、使うのはSSR無しだと同じコンテンツだよね。だからpathinfo使うんだよね。
頭おかしくなってるのはこのへん。

で、画面切り替えではなく、手入力で変なアドレス入れられると、
「切り替えるはずの画面が無かった」なんて判断は、JS側にしか出来ないよね、って言ってる。

**デフォルトの名無しさん** · 2018/02/18(日) 14:54:06.49

>>938
ダム端もレンダリングしてくれるよ。
エスケープシーケンスで。
お前色々知らなすぎるだろ。

**デフォルトの名無しさん** · 2018/02/18(日) 14:56:10.32

>>937
> サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。

コンテンツとHTTPステータスは別。

同じコンテンツを返しても、HTTPステータスは違っても良い。
極端な話、404を返しながら、コンテンツを返すことだってある

それからSPA（それはクライアントの話）によってサーバーが挙動を変えるわけじゃない。
サーバーにとってクライアントがなにでどうやって動いているかは関係ない

（サーバー側が手抜きだから）HTTPステータスが全部200を返してしまう。
ページがなくても200を返してしまう。って話だから
それならサーバー側をちゃんと作りましょうで終わる話

**デフォルトの名無しさん** · 2018/02/18(日) 14:56:39.90

>>940
コンテキスト理解してないのか？
このスレで言うレンダリングとは、HTMLのレンダリングだよ
馬鹿かｗ

**デフォルトの名無しさん** · 2018/02/18(日) 14:57:37.94

SPAはアプリケーションであって、Webページの軽量版でもおしゃれ版でもリロードなし版でも無い。
一つの画面に1リクエストでもない。
アプリケーションなんだから。
こいつの頭の中でポップアップする子画面とかどう処理されてるのか謎過ぎる。

**デフォルトの名無しさん** · 2018/02/18(日) 14:58:27.50

>>941
違うよね。手抜きだからではなく、知り得ない情報だから、200何だよ。
お前バカなの？

**デフォルトの名無しさん** · 2018/02/18(日) 14:59:24.98

>>942
うん？
ただレンダリングするだけなら、ダム端と同じ、は

ただHTMLをレンダリングするだけなら、ただエスケープシーケンスをレンダリングするダム端と同じだ、と言ってるんだが。

コンテキスト読めてる？

**デフォルトの名無しさん** · 2018/02/18(日) 15:05:53.24

>>939

> >>936
> なんで忘れなければいけないんだ…？
> >>834
> が発端だろ。

だから、SPAがどうのこうのって考えてる事自体が間違いなんだよ
>>834のリンク先のソフト404エラーの内容見てみ？
SPAの話であるとか全く関係ない

リンク先引用しようか？
> ソフト 404 エラーとは、サイトの URL にアクセスしたときに、
> ページが存在しないことを示すページと 200 レベル（成功）のコードがブラウザに返されることです

「サイトの URL にアクセスしたときに」って書いてあるだろ。
SPAでもなんでも構わないが、サイトのURLにアクセスしない時には全く関係ない話。

（SPAで）サイトのURLにHistory APIで変更すると、サーバーにアクセスしなくても画面に表示できる～とか
いいだすから、おいおいってなる。前提が違うだろ。サーバーにアクセスしない時は考える必要がない。
サイトの URL にアクセスしたときの話なんだから

ただのa要素のリンクだろうがHistory APIで変更しようが関係ない。どちらも同じURLだ。
そのURLに対して「サイトのURLにアクセスした時に」404を返すのがソフト404対策なんだよ。

で、発端の>>834へのレスだ
> SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？

「サイトの URL にアクセスされたときに」データがなければ404を返せばいい
SPAとか考える必要はない。

**デフォルトの名無しさん** · 2018/02/18(日) 15:07:32.04

>>945
ダム端の定義がしたいなら、どっかよそでやれ

**デフォルトの名無しさん** · 2018/02/18(日) 15:08:12.87

>>946
だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。
お前が最初の時点から読み間違えてるの。
バカなの。
いいかげん認めて。めんどくさくなってきた。
技術者なら知らないことを知りませんでしたと言うのは大切だよ。

**デフォルトの名無しさん** · 2018/02/18(日) 15:09:00.51

>>947
ウキウキとダム端について間違った事語って、知らない事が出てきたらこうなる。
楽な生き方だな。

**デフォルトの名無しさん** · 2018/02/18(日) 15:10:01.70

俺は降りる。ずっと勘違いしとけ。

**デフォルトの名無しさん** · 2018/02/18(日) 15:10:43.79

>>948
> だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。

404ってサーバーが返すものだぞ？
サーバーがデータがないとクライアントに返すものなのに、
データが無いか知ってるのがアプリケーション？
サーバーと関係ない話なら最初から404とか200ですら出てこないだろ。
問題になるどころか、問題そのものがない

**デフォルトの名無しさん** · 2018/02/18(日) 15:16:19.87

ん？もしかして>>834もそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか？

**デフォルトの名無しさん** · 2018/02/18(日) 15:19:01.00

404はHTTPプロトコルレベルの話なんだから、

仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404（200も）はでてこない。

これは常識だよね？
ここまではいいよね？

**デフォルトの名無しさん** · 2018/02/18(日) 15:36:21.08

そもそも>>834の言う

>SPAを作る時にページが存在しない場合に

の解釈が違っている気がする。
俺はそもそもどういう状況のことを言っているのか理解できなかったが。

**デフォルトの名無しさん** · 2018/02/18(日) 15:46:08.25

一切アクセスをしないと言えど、リロード時にはリクエストは飛ぶからな。サービスワーカーにでも。
その時帰ってくるのはコンテンツとしては200、ただしHTML/JSが表示するのは存在しないというエラーになるだろうが。

プロトコル上の404と、ソフト404(≒200)はもちろん区別ついてるが、一般的にソフト404と呼ぶんだよ。
ソフト404ってのはプロトコル上のエラーコードを概念的な名前として使ってるだけであって。

お前が、周りが何を問題にしてるかわかってないんだろう。

いろんな問題をごちゃまぜにした結果馬鹿な事言ってると思いたいわ。

**デフォルトの名無しさん** · 2018/02/18(日) 15:48:40.21

>>954

俺はHTTPステータスコード404を返したいんだから、
HTTPプロトコルでサーバーにアクセスのは当然の話として

> SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？
というのは今現在200が返ってきてしまって困っているという状況には
>>917 で説明したパターンで起こるのを知っているからその話だと理解した

下手な作りだと、例えば http://example.com/foo/1 でデータがなくて
普通のウェブアプリだと404が返ってくる状況でも、（下手な）SPAの作りだと
>>917みたいに一旦 SPA（Single Page Application）のシングルに相当するページを表示してから、
（404になる）データを読み込むという流れだから、200になってしまう。

これを404にするにはどうすればいいかの話をしていたんだが？

そうか、やけにサーバーにアクセスしないことも有るって強調していたのは
HTTPリクエストを伴わないからそもそもHTTPの404の話なんかでてこないことに
気づいていなかったんだろうな。その時点で話について来れてなかったのか

**デフォルトの名無しさん** · 2018/02/18(日) 15:52:23.09

>>955
> 一切アクセスをしないと言えど、リロード時にはリクエストは飛ぶからな。サービスワーカーにでも。
> その時帰ってくるのはコンテンツとしては200、ただしHTML/JSが表示するのは存在しないというエラーになるだろうが。

サーバーにリクエスト投げてデータが無いなら404を返せよ。アホかｗ

サーバー側の実装がクソだから200になるんだろ
>>834はそれをやめたいって話だろ
（なんでやめたいかの話でSEOに脱線したわけだが）

**デフォルトの名無しさん** · 2018/02/18(日) 16:00:36.45

違うよ。

SPAだと、example.com/
以下はHTTPで返すものは同じコンテンツを返して当然だと言ってるの。
例外はexample.com/api/xxxxみたいなAPIのURL。　
その後についてくるfoo/1というのは、アプリケーションに対するパラメータであって、HTTPサーバがハンドリングする「ための」ものではない、と。

example.com/history/2017
というURIは、historyの2017分、というSPAへのパラメータであって、それが存在するかどうかはHTTPサーバは知りようが無い。
というか、historyが存在するかどうかも関係ない。

アプリケーションは、history/2017というルートから、適切なコントロールとapiで、ログイン認証したり、履歴ページを表示したり、そこに、ログインユーザ(またはpuiblicな)の2017年分のデータをapiから取得して並べたりする。
apiのレスポンスとして404もわかるが、その404は200データなしとは異なるよね、ってのが前半に言ってた事で。

200になってしまう、と言うのは話がおかしくて、200で当然だが、なんだよ。
レスポンスを404にしたいんじゃなくて、404というレスポンスの値に相当する表示を表現するにはどうしたら良いか、の話だろ。

**デフォルトの名無しさん** · 2018/02/18(日) 16:01:57.46

> SPAだと、example.com/
> 以下はHTTPで返すものは同じコンテンツを返して当然だと言ってるの。

ほんと呆れる。クライアントのことなんかなんけいないって言ってるのに
まーだクライアントがSPAで動いているとーとか言ってやがる

**デフォルトの名無しさん** · 2018/02/18(日) 16:02:58.40

>>957
違う。お前は本当に馬鹿なんだと思う。
そして、データなしは404とは違う。404は未検出、だ。データなしは200の空レスポンスとは相当意味合いが違う。