+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
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です） >>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があることは必須 >>891
React-router-dom触ってると
onclickで遷移する仕組みがチュートリアルで紹介されてないんだよね。
(よく探すとあるけど。)
GoogleBotが辿ってくれるためにはAnchorである必要があるってことで
そのためにonClickじゃなくてLinkタグを使って遷移処理するようにするってことだね。
非同期通信を介してレンダリングすると一々Stateに保存してLinkタグを書くのがシンドいと思ってたんだけどSEOのためだったんだなぁ なってるといいよねｗ
どちらにしろURLがないコンテンツは
クロールしてくれないことに変わりないんだがな >>892
リンクタグを使った所で、そのリンクを
アドレスバーに入れて表示されないと意味ないからね
クローラーはリンクのみを取り出してアドレスバーに入れて
表示されたものを、そのURLのコンテンツとして認識する
そこからクリックして変化したものまでクロールしてくれない
（普通に考えれば当たり前だが） クリックじゃなく遅延して表示してるのはどうなるんだろ？何秒か適当にwaitしてから取ってんのかな？それとも >>895
運次第だろ？
1秒毎に変わるページでも作って、それがクロールされるかとか
やってみたら？少なくとも全部クロールされることはないだろうね
クリックされると副作用が現れるということで、
ページ上にクリックできるものが複数あって、
じゃあどれをクリックしたものをクロールされるのか？とかさ
考えてみれば不可能だってわかると思うんだが
クローラーがJavaScriptを実行するというのは
JavaScriptで動的に出したもの全てをクロールして
くれるわけじゃないことはわかるでしょ？
クロールされるのは指定したURLを表示して（JavaScriptで）
レンダリングした最初の画面ぐらいに思っておいたほうが良いよ
そこからのonclickは動かないとみなした方がいい
もちろんレンダリングした結果に含まれるリンクにはURLが書いてあるので
新たなクロール対象になる。
onclickの場合はURLが書いてないのでクロール対象にならない onclickにlocation.href='hoge/fuga.html'とか書いてあったらどうなんの？ とりあえず、404って書いた画面表示しときゃいいだろ。
それで不満だって言うのなら何が気に入らないのかちゃんと挙げて議論。 >>898
あるURLに対してクローラーがアクセスしてくる場合には
サーバーサイド側で404を表示できる。
なぜならサーバーサイド側でそのリクエストを処理するから
その時にデータがなければ404を返せる
Ajaxを使ってアクセスする場合は、そのリクエストで404を返せばいい 何を怒り狂ってるかわからんが、クローラがちゃんとクロールしてるかどうかの調べ方は書いただろう。
>>889
ページ内部の話だから、むしろ関係ないんだよ。
SPAなんだから。
ウェブページ豪華版みたいな扱いされても困るわ。
SPAが重いって問題とは別問題。
>>890
URLじゃなくてURIとしては持つだろうね。
持つって言ってるでしょ。
それはユーザにとっての識別子であって、クローラに対してどうするかは、クローラがクライアントとなってどうするかによる。
その調べ方は書いた。
なんか大きめの勘違いしてない？
SPAはwebページとは限らないよ。 ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。
そのURIの情報をDOMごと貰えばいい話になる。
どこのClassicASPのUpdatePanelの話なのかわからんレベルで無能じゃん。
アプリケーションだよ。 > ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。
あ、なるほどｗｗｗｗｗ
そううかお前、サーバーサイドでレンダリングするって思っちゃってるんだｗｗｗｗ
SPA初心者だな。
クライアントでレンダリングするのに必要なデータをJSONでHTMLで埋め込むんだよ
そしてクライアントサイドでレンダリングするんだよ。
>>889のリンク先にもそう書いてあんだろ
で、クライアントでレンダリングするためのデータがなかったら、
404を返すだけの話だよ。 >>901
> SPAはwebページとは限らないよ。
え？なに？ お前のSPAはF5押したら
初期画面に戻っちゃうの？
使いづれぇなぁｗ F5押しても戻らないよ。
ルーターが処理してるから。
お前アホなんだろ。 そもそも、pathinfo使ってリダイレクトさせるのは別に動的なphpやサーブレットなんかだけが対象じゃなくて、htmlでも良いんだよ。
そのhtmlはサーバから取らなくてもサービスワーカーなりなんなりでブラウザ内で処理しちゃえるから、トラフィックは発生しない。
ブラウザ内でindexedDBなり使って復帰すればそれでいいんだから、同じURIにリクエスト投げる必要もなく、ブラウザ外に問い合わせて表示データを取る必要もない。
アプリケーションなの。APIが返す値を表示するだけのブラウザじゃないのよ。SPAと言うのは。 >>905
F5押しても戻らないってことはURLがあるってことじゃねーかｗ >>907
URIはあるけど、それがサーバのURLと一致してるわけじゃないよ。
理解してなくない？ F5で完全に戻らないとしてもURLだけで
そのアプリケーションの全ての値が復元できるとも限らない それはURIだけで、サーバがすべての値を返すとは限らない、と同じ意味だよね。 クローラーはURIだけでアクセスしてくるので
URIから読み取れないデータはクロールされません。
またGoogleの検索結果にSPAのJSONが
クロールされた形跡は見られませんね。
もしそのJSONがクロールされていれば
検索結果に出るはずですから その理屈は正しくない
もしJSONも認識できて人並みの知能があった場合
それを検索結果に出さないという判断をすべきだから SPAのJSONという時点でダム端みたいな使い方しかして無いとわかってしまう悲しさがあるな。
ブラウザは単なるレイアウトエンジンじゃないぞw
うちのログにはSPAだけがルーティングしてるアドレスに向かってのクエリはあるから、逆にajaxしてるからクローラにそこで諦められてんじゃないの？ よくよくこいつがなんで馬鹿な事言ってるか考えてみたんだが、URIだけでアクセスしてくるが、その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリングできてしまうがある事を想定してないんだろうな。
URIで指定されたコードをバーコードとして画面に表示するとか色々作ったが、そう言うのは多分想定外なのかなと思ったわ。
HTTPとしてGETするリソースと、ブラウザにあるコンテンツを求めるために示されるURIはイコールじゃない。
だからHTTPサーバはindex.html/jsに相当する内容をいつでも同じように返すし、サービスワーカーが動いてればそのサーバへの問い合わせすらしない。
いつでも、そのhtmlやjsが、自身に与えられたURIから、コンテンツを作る。 >>901
この文脈であえてURLとURIを区別する意味が分からん。 >>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を返すことができる。 >>917
違うよ。3は、必ずしも存在しないって言ってるの。
SPAでは2回リクエストを送ることもあるだろうし、リクエストを送らない事もあるって言ってるの。
まともなアプリケーションでは、一回も送らなくて済むならば送らない。
htmlやjsをサービスワーカーでキャッシュしてれば、そもそももっと話が変わってくる。
(特定のURI以下へのリクエストをサービスワーカーでキャッシュから解決するだけ)
さらに、URIの中身で画面が作れる場合、アプリケーションから見てそれは本当に唯一無二のURIだよ。Locatorではなく、Identifier。
お前は、最低一回リクエストするはずだ、という思い込みというか、それ以外の方法を知らないんだと思うよ。
要はウェブページプラスαの考え方。 >>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のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）
クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？ それなにもクロールしてないからｗ クローラーの使命を果たしていない それって今のGoogle Botの話でしょ？
クローラが一般的にそうである必要はないよ
Google Botも重要なサイトでは高機能長時間のクロールをしてるって噂もあるし クソみたいな長文で自分の理解が及んでませんでしたって言い訳されても困るわ。
それも織り込んで話してる。 >>920
長時間クロールっていうのはたくさんのページを
まとめてクロールしてるってだけ。動きは変わらない。
> クローラが一般的にそうである必要はないよ
個人的にしか使わないクローラーは別として
一般的なクローラーは、不特定の人が見るわけだから
このような動きになる。 要はURIだけで画面が作れる画面ってのはあるんだよ。
URIがデータの時な。
クライアントサイドだけで(JSで処理される)リンクをたどる、のはやってくれてるよ。
リファラ見るとわかる。
そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。
ajax！json！ブラウザに上のURLと同じURLでAPIがjsonを返すんだ！と狂って叫ぶ前に、ちゃんと理解すれば良いのに。
ブラウザ上のURLと同じURLで実はJSONを返してる、とか、逆にクローラは無視しにかかるだろ。
クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
SPAなんにもわかってねえな。 >>921
SEOの話とは違うね。
ページが見つからない時、どうやって404を返すべきかどうかの話
SPAがどうたらとか、サーバーにアクセスしないときがどうとか
言っているが、それらは全く関係ないってことを言ってる。
普通にサーバーにアクセスされた時にデータがなければ404を返せばいい
どんなページもURIを持っていればサーバーにアクセスされうる
（その典型的な例がクローラーってだけの話）
サーバーにアクセスしないときは〜なんて考える必要はない。
そもそもアクセスされないなら何も出しようがないだろ？ >>925
> 要はURIだけで画面が作れる画面ってのはあるんだよ。
> URIがデータの時な。
URIがデータだったとしても、（そもそも全てのURIがそうなんだがｗ）
話は関係ない。
URIを持っていればサーバーにアクセスされうる
SPAの場合にサーバーにアクセスしない場合もあるってだけで
ブラウザでF5を押したりクローラーからアクセスされる。
だから必ずしも作る必要はないが、ちゃんと作るならば
サーバー側の処理は必要。その時にデータがなければ404を返せばいい
（URIの情報しか使わないというのならそれは200だろうけどな）
> クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
> SPAなんにもわかってねえな。
そもそもレンダリングする前に、クローラーはSPAであることもわすれて
URIに対してサーバーにアクセスする。ここでSPAのことを考えること自体が意味ないんだよ
ちゃんと作るならば、サーバーにアクセスされた時に必要なデータがなければ404を返せばいいだけ
データの有無の話でAjaxによるアクセスかどうかとかの違いも考える必要はない。
どんな内容を返すか？のために考えるのであって、データがないときは404 >>927
だから、サーバにアクセスされても、indexと同じものを返すよ。サーバからのリソースは。
F5を押されたって同じだ。
そのURIにデータがあるか無いかは、クライアント次第なんだから、サーバが返すのは不可能。
もちろんデータのうち、ユーザが作るようなもの、クローラがそもそも「生成しようがない」ものは拾えなくて当然というか、
クローラには一生生成できないURIで表現されるので、検索結果には上がらんし、そういうデータの一覧画面は空として上がるだろう。上がらないようにしたけど。
ただ、アプリケーションだけがハンドリングする静的なコンテンツ、はクローラが拾う。
それはサーバリソースと全く関係なく、jsにバンドルした内容から描画してる画面なんかも含まれるわな。
OSSのライセンス一覧とロゴのaboutなんかとか、特定のコンポーネントだったり、色々あるだろうが。
お前が言ってるSPAはアプリケーションと言うより、ブラウザのレンダリング力を借りたダム端なんだろう。
ダム端知らないなら早めに言ってね。言い換えるから。 >>925
> そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。
そういう話はしてないんだなぁｗ
SPAでページがない時に404を返したい。どうすればいいか。という話
答は、今までと何も変わらない。
サーバーにアクセスした時にページを表示するために
必要なデータがなければ404を返せばいい
反論としてSPAだとサーバーにアクセスされない場合が〜とかいうから
どのページでもURIを持っていれば、サーバーにアクセスされる可能性があります。
特にクローラーは必ずサーバーにアクセスしてきます。
その時に404を返せば良いのです。という話 >>928
お前、前提がおかしいぞ？
今は、サーバーにデータが無い場合に404を返すにはどうするかの話だ
そもそもHTTPステータスはサーバーが返すもの。サーバーでしか判断できない
ダム端も全く関係ない話。クライアントの端末がなにであるかとか
クライアントがブラウザとかクローラーとか、SPAか否かとか
そういったクライアントは完全に無視できる話なんだよ。
お前が言いたいのはクライアントが○○の場合には〜と
全部クライアントの話ししかしてね〜じゃんか
クライアントは関係ないんだよ。忘れていい。 クライアントが関係ないっていうのはクローラーの例を使っても説明できる。
つまり、あなたのクライアントと、私（クローラー）のクライアントはデータを共有していません。
あなたのクライアントでは何かデータが表示されるんでしょうが、
私（クローラー）のクライアントはあなたのデータなんか知りません。
あなたのクライアントでSPAが動いていようが
私（クローラー）のクライアントでは動いていません
ってことなんだよ クローラーが高度なレンダリング機能を備えているから
JavaScriptが動くっていうのも、クライアントの話なんで関係ない
単にレンダリングするってだけ
ここでSPAが〜とか言ってくるやつは、
レンダリングされる＝SPAとしてクローラーが動くって
考えちゃってるんだろうなって思う。
もう少し具体的にいうと
クローラーが、Aというページを読み込んで表示されたBというリンクをクリックして
（History APIでURIが変わった時に）A+Bとなった情報を保存する
と思い込んじゃってるんでしょう？
そういうクローラーを作ることは可能だが、そんなことはしない。
なぜなら、Bというリンクをクリックした時にサーバーにアクセスしないかもしれないから
それを許すとクローラーのマシンの中だけで無限にアドレスが作れる。
しかもそのアドレスは他人がアクセスできるとは限らない。
クローラーというクライアントが生成したクローラー専用のURIになる。
実際の動きはこう
クローラーが、Aというページを読み込んで表示されたBというリンクを巡回するURIとして記録する
別のタイミングでHistoryAPIなんか使わずにBというURIでサーバーにアクセスして表示されたものを保存する
で、ここで重要なのは クローラーの "例から" 分かる通り URIを持つならばサーバーにアクセスする可能性がある
サーバーにアクセスされた時に404を返せば良いんだよっていう話をしている。 >>929
だから、結論を言うと、SPAで404にあたる場合に、表示するかなんてサーバが関与する事ではない。
ルータの二重管理にもなる。
だから、SPAでソフト404を出すしかない。
って言ってるんだが。 >>931
>>932
その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。
お前は2010年あたりから進化してないのかよ。
あと、クローラのクライアントでもレンダリングされてるよ。
確認してこいよw >>933
だからSPAなんて忘れろってｗ
SPAを使おうが使うまいが、サーバーにアクセスされる時に
データがなければ、サーバーが404を返せばいいだけだって言ってる。
URIを直接ブラウザで開くならば、そのタイミングで404を返せばいいし、
History APIでURIを変えただけならば、その時にAjaxでリクエストあればそのタイミングで404を返せばいい
（その時にAjaxでリクエストがなければそもそも404を変えしようがない）
404をどう返すかの話をしていて、404をどう表示するかの話はしてないんだよ。 サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。
だから頭おかしい発想になってるんだと思うが。
404である、とか、一旦Webページの発想から離れられないもんか、
Dreamweaverでシコシコ画面作ってる「ウェブ屋」でもあるまいし。 >>934
> その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。
https://www.nttpc.co.jp/yougo/%E3%83%80%E3%83%A0%E7%AB%AF%E6%9C%AB.html
> つまりダム端末は、自分で計算したりデータを保存したり出来ない“頭の悪い端末”という意味で、
>英語では dumb-terminal（ダム・ターミナル）という。それを日本語化して
>「ダム端末」、略して「ダム端」と呼ぶことも多い。
レンダリングする頭があればダム端にはならんが？w >>936
なんで忘れなければいけないんだ…？
>>834
が発端だろ。
URLをブラウザで叩いて、404であるかどうかって時点で違うよね。
ajaxがどうのと言ってるけど、ajaxなんか発生しない、単なる画面切り替えのhistoryAPI操作もあるよね。
それは、もとの画面が切り替わった状態、として扱われるべきだよね。リロードの時。
でも、使うのはSSR無しだと同じコンテンツだよね。だからpathinfo使うんだよね。
頭おかしくなってるのはこのへん。
で、画面切り替えではなく、手入力で変なアドレス入れられると、
「切り替えるはずの画面が無かった」なんて判断は、JS側にしか出来ないよね、って言ってる。 >>938
ダム端もレンダリングしてくれるよ。
エスケープシーケンスで。
お前色々知らなすぎるだろ。 >>937
> サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。
コンテンツとHTTPステータスは別。
同じコンテンツを返しても、HTTPステータスは違っても良い。
極端な話、404を返しながら、コンテンツを返すことだってある
それからSPA（それはクライアントの話）によってサーバーが挙動を変えるわけじゃない。
サーバーにとってクライアントがなにでどうやって動いているかは関係ない
（サーバー側が手抜きだから）HTTPステータスが全部200を返してしまう。
ページがなくても200を返してしまう。って話だから
それならサーバー側をちゃんと作りましょうで終わる話 >>940
コンテキスト理解してないのか？
このスレで言うレンダリングとは、HTMLのレンダリングだよ
馬鹿かｗ SPAはアプリケーションであって、Webページの軽量版でもおしゃれ版でもリロードなし版でも無い。
一つの画面に1リクエストでもない。
アプリケーションなんだから。
こいつの頭の中でポップアップする子画面とかどう処理されてるのか謎過ぎる。 >>941
違うよね。手抜きだからではなく、知り得ない情報だから、200何だよ。
お前バカなの？ >>942
うん？
ただレンダリングするだけなら、ダム端と同じ、は
ただHTMLをレンダリングするだけなら、ただエスケープシーケンスをレンダリングするダム端と同じだ、と言ってるんだが。
コンテキスト読めてる？ >>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とか考える必要はない。 >>945
ダム端の定義がしたいなら、どっかよそでやれ >>946
だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。
お前が最初の時点から読み間違えてるの。
バカなの。
いいかげん認めて。めんどくさくなってきた。
技術者なら知らないことを知りませんでしたと言うのは大切だよ。 >>947
ウキウキとダム端について間違った事語って、知らない事が出てきたらこうなる。
楽な生き方だな。 >>948
> だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。
404ってサーバーが返すものだぞ？
サーバーがデータがないとクライアントに返すものなのに、
データが無いか知ってるのがアプリケーション？
サーバーと関係ない話なら最初から404とか200ですら出てこないだろ。
問題になるどころか、問題そのものがない ん？ もしかして>>834もそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか？ 404はHTTPプロトコルレベルの話なんだから、
仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404（200も）はでてこない。
これは常識だよね？
ここまではいいよね？ そもそも>>834の言う
>SPAを作る時にページが存在しない場合に
の解釈が違っている気がする。
俺はそもそもどういう状況のことを言っているのか理解できなかったが。 一切アクセスをしないと言えど、リロード時にはリクエストは飛ぶからな。サービスワーカーにでも。
その時帰ってくるのはコンテンツとしては200、ただしHTML/JSが表示するのは存在しないというエラーになるだろうが。
プロトコル上の404と、ソフト404(≒200)はもちろん区別ついてるが、一般的にソフト404と呼ぶんだよ。
ソフト404ってのはプロトコル上のエラーコードを概念的な名前として使ってるだけであって。
お前が、周りが何を問題にしてるかわかってないんだろう。
いろんな問題をごちゃまぜにした結果馬鹿な事言ってると思いたいわ。 >>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の話なんかでてこないことに
気づいていなかったんだろうな。その時点で話について来れてなかったのか >>955
> 一切アクセスをしないと言えど、リロード時にはリクエストは飛ぶからな。サービスワーカーにでも。
> その時帰ってくるのはコンテンツとしては200、ただしHTML/JSが表示するのは存在しないというエラーになるだろうが。
サーバーにリクエスト投げてデータが無いなら404を返せよ。アホかｗ
サーバー側の実装がクソだから200になるんだろ
>>834はそれをやめたいって話だろ
（なんでやめたいかの話でSEOに脱線したわけだが） 違うよ。
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というレスポンスの値に相当する表示を表現するにはどうしたら良いか、の話だろ。 > SPAだと、example.com/
> 以下はHTTPで返すものは同じコンテンツを返して当然だと言ってるの。
ほんと呆れる。クライアントのことなんかなんけいないって言ってるのに
まーだクライアントがSPAで動いているとーとか言ってやがる >>957
違う。お前は本当に馬鹿なんだと思う。
そして、データなしは404とは違う。404は未検出、だ。データなしは200の空レスポンスとは相当意味合いが違う。 > 一切アクセスをしないと言えど、リロード時にはリクエストは飛ぶからな。
自分でリロードした時にサーバーにリクエスト飛ぶと言ってるくせにｗ
> その後についてくるfoo/1というのは、アプリケーションに対するパラメータであって、HTTPサーバがハンドリングする「ための」ものではない、と。
HTTPサーバーがハンドリングするだろ。その時に404返せって
言ってるのにこいつは理解しない
お前の作ったクソSPAは200を返すんだって何度も繰り返し言わなくてもわかってるわ
それがクソだから修正して404を返すようにしろって話だ。 >SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？
なんだから、SPAの話をして当然だろ。
SPAよくわかんないから旧石器時代の話します、とかもう間抜けすぎるからやめて。 >>962
違うよね。
HTTPサーバは関与できない。
その処理はクライアントの実装次第で、サーバ側の処理としては存在しないから。
その二重管理は間違ってるし、ユーザしか知り得ない情報をサーバに持ち込むのは全く持って意味が無いというかデメリットしかない。
ユーザしか知り得ないことを正しく知らないのは大切。
だから、HTTPサーバは、pathinfoでなりなんなり、好きな方法で良いが、静的なコンテンツを吐く。
そもそもお前は404の意味もちょっと間違ってる。 >>960
> そして、データなしは404とは違う。404は未検出、だ。データなしは200の空レスポンスとは相当意味合いが違う。
リソースとして考えろ、中の実装は忘れろ。
URI、例えば http://example.com/foo/1 というURIで示したい
リソースをNot Foundとしたいなら404だ。
http://example.com/foo/1 を表示した時、周りに広告やらカテゴリやら
いろんなデータがついてることよくあるよな？ 例えそんなのがあったとしても
「http://example.com/foo/1 というURIで示したいリソース」がないなら404にするんだよ
SPAのhtml/jsがあったからって200にするな
抽象化して物事を考えられないのか
基準は「http://example.com/foo/1 というURIで示したいリソース」だ
まわりの関係ないもので判断するんじゃねーよ >>962
そもそも、ページ(正確にはSPAの画面)は存在するんだよ。
そして、画面は一つのリソースから構成されてるわけじゃないんだから。
200で画面出して、集まったデータ分表示するのはまっとうでしょ。
そこで、APIが200のデータなしではなく404返したなら、完全なるエラー画面に飛ばす必要があるかもしれんが。 >>963
お前、質問者が
HTMLを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？
っていったら、HTMLの話すんのか？
404を返すのはHTTPサーバー（or ウェブアプリ）なんだから、
質問者が関係ないものを持ち出してきたものとして、HTMLの話ではなく
HTTPサーバー（or ウェブアプリ）の話をするだろ >>966
画面が存在するのと404を返すのは別の話
カスタム404ページとか調べてこい
画面は存在するが、404を返している。
そして忘れんなよ？ HTTPステータスコードは
HTTPプロトコルで、サーバーにアクセスした時に
サーバーから返す時に使うものだ >>965
リソースとして考えて、空と、見つからない、は断じて違うもの。
実装論だと、apiの互換性がなくなって旧ver消したなら、APIが見つからない、404。
apiはあってて、処理も正しく行われて、データなかったよ、は404とは限らない。
なら、APIが見つからないと切り分ける必要あるよね。
抽象化すると、
あるものは200
見つからないものは404
あったけど中身入ってないよ、は200
探し方が悪い、は400
お前には見せられない、は403
名乗れ、は401
サーバとして答えられん、は500系。
お前が抽象化できてないよ。
完全な実装論じゃん、 >>968
それも知ってるよ。知ってるからこういう話してるんだよ。
お前が言ってるリソースは、全部旧石器時代の話。 >>967
このどうやって404を、ってのは、存在しないものをどうやったら手に入れられるか、って話であって、
たとえ話に近いだろ。
そこに、いや、ajaxが、とかアスペのようにHTTPサーバについて一所懸命に勉強したつたない知識で騒がないで。 「URIが指し示すリソース」っていうのが分からんのかもなｗ
例えば以下の適当なページは404を返してくる
https://support.google.com/websearch/answer/dsfasdfasdfa
だが、画面上は検索ボックスやGoogleアプリのリンクや
ログイン状態といった「リソース」が表示されてる
>>966の馬鹿げた理屈では
> そして、画面は一つのリソースから構成されてるわけじゃないんだから。
> 200で画面出して、集まったデータ分表示するのはまっとうでしょ。
この適当なページにたいして>>966では200を出すのがまっとうだと言っているが
見ての通り、googleはそんなことはしていない。
なぜなら「URIが指し示すリソース」というのは（これはヘルプなので）
ペルプの1ページのことで、まわりにあるごちゃごちゃしたリソースのことではないから
もちろんこの周りにあるごちゃごちゃしたリソースにSPAのシステムも含まれる
画面が出るから200とかアホすぎｗ SPAだから200にするんだとかアホすぎｗ
200にするか404にするかは「URIが指し示すリソース」の存在の有無が基準だ 例示するとこれとかかな。
https://www.google.com/maps/search/aaaaaaasa/
200、該当する場所無しでアプリ開くよね。
お前の理屈ガッバガバ。 一つの画面が一つのリソースからできてるわけでないってのもわかるか。
画面を動かすとアドレスが変わるけど、リロードしてもSSRしていないリソースはそのまま落ちてくるのもわかるな。 >>979
そっちはWebページ、俺が挙げたのはSPA。
だから、おまえは旧石器時代の人間で、Webページからはなれて考えろって俺が言ってるの。 SPAでも同じ話だろ、って言いたいんだろうが、全然違うことがわかったよな。
技術についてこれねえやつは発言しないでくれるかな。
COBOLでは〇〇だった、とかドヤってくる無能そっくりなんだわ。 あ、なるほど、こいつURIリソースが見つからないのと
検索結果が見つからないをごっちゃにしてるのかｗ >>983
違うよ。
中でAPI呼んでるでしょ。
そのレスポンス見てみ？
これ以上間抜けさらさんと謝ればどうだ？ >>981
> そっちはWebページ、俺が挙げたのはSPA。
SPAで404が返ってこないものを出して
200が返ってきましたーって意味ねーだろｗ
SPAを使って404を返してくるものをもってこいって。
画面に地図表示されて明らかに404じゃないのに
404でてないとかいわれてもな（苦笑 >>984
APIレスポンスの中で404になるべきものってどれですか？ だからURIとURLを区別してたのに、アホなのかな。 >>985
だから、帰ってこないものなんだよ。
そう言ってんじゃん。
今回のアドレスも、404に相当するsnack出てるよねw レス数が950を超えています。1000を超えると書き込みができなくなります。
