元スレ+ JavaScript の質問用スレッド vol.128 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

551 = :

テンプレートエンジンとか考えたらいいじゃん
普通は変換済みのコードをキャッシュしてそっからアクセスするようにするでしょ
テンプレート（ページ）が変更されたらキャッシュの中身も変更されて
テンプレート（ページ）が削除されたらキャッシュも削除されるけど
半永久的にキャッシュは存在してる

552 :

>>538
なるほど、確かに

553 = :

よくわかんないおはなしは横に置いといて
>>528はYesかNoかで言えばYesでいいんだよね？

556 = :

奴隷かな

557 = :

>>553
Noだよ
それ以上の回答をするには
質問者がどう考えてるかの情報がもっと必要

558 = :

LocalStorageと対比して聞いてんだからLocalStorageのような使い方を望んでいるのだろう
SWの他の使途としては>>533が色々書いてるけど
とりあえず>>530は実現出来ると示唆しておきながら役割が違うから対比出来ないってなんかおかしい

559 = :

いやいやいや……
ファイルをキャッシュするのはCacheStorageのほうで、
それをServiceWorkerで使うこともあるが、
CacheStorageは別にメイン側でもどこでも使える。
ファイルのキャッシュはServiceWorkerの機能ではない。
ServiceWorkerはあくまで少し付加機能のあるSharedWorkerなのだから、
どうかんがえても対比するのはおかしい。

560 = :

うましか不毛論争たな

562 = :

これは争いなのか？

563 = :

争いではない。一方的な虐殺だ。

565 = :

ネットワークプロキシってバッチみたいな定期実行やプッシュ処理できるんだ

566 = :

いろいろ挙がった名前のうち、
どれがCOOKIEと同じようなただの文字列保存で
どれがファイル単位のキャッシュなのですか？

567 = :

>>564
説明がずさんな上に今度はコピペかよ…

568 = 554 :

>>567
説明しても「よくわかんないおはなし」になるんじゃないのか？
文句があるならおまえさんがもっと判りやすく説明してくれ
下記URLを読め、以上
http://www.atmarkit.co.jp/ait/articles/1108/12/news093.html
http://www.html5rocks.com/ja/tutorials/service-worker/introduction/

569 = :

>>568
後者のURLの例を見るに、ただの文字列データではなくURL≒ファイル単位でのキャッシュに見えるんですけど
じゃあなんで>>554なんですか？

570 = :

>>568
逆だろ
説明できんならいちいち書き込まんでよろしい

571 = :

てめえの持論勝手に展開してソース嫁で逃げるとかおまえ何しに来たの

572 = :

なんでここ関係ない素人が回答しにきてんの？

573 = :

>>570
説明できないと思ってるのはおまえだろ
更に良い説明で反証してくれ

574 = :

回答が間違っているなら訂正すればいいじゃない(俺はわからないから正せないけどさ)
何でここの人たちは攻撃的で中身のない煽りばかりするんだろ

575 = :

>>573
意図しているのはCacheAPIであり
ServiceWorkerが使うCacheはファイル単位でのキャッシュと言って問題なかろ
説明という行為で悦に入る遊びがしたいなら他の板でやれ

576 = :

どうしても嫌味を加えないと気がすまない性格なんだな…
だから、このスレは荒れるんだよ

577 = :

アスペヲタの典型だろこんなとこで偉そうにしてるやつなんて

578 = :

回答が正しく質問者の欲求を過不足なく満たし一分の隙もないなら偉そうにしようが草生やそうが構わんよ

580 = :

そもそもServiceWorkerという言い方でも別に間違いじゃないんだが
CacheAPIがServiceWorkerという仕様の一部だし
http://www.w3.org/TR/service-workers/

581 = :

尻尾巻いて逃げたくせに堂々とかえってくんじゃねえよはげ

582 = :

フルボッコｗｗｗｗ

583 = :

こういう輩を呼び寄せるから回答交えて煽るのは勘弁して欲しいわ
煽っても許されるという空気がいかん

584 = :

煽るやつは許さん

585 = :

煽るやつも煽られたやつも全て許すよ
みんな許すよ
許されないのは俺だけで十分さ

586 = :

便乗質問
ServiceWorkerはセキュリティのためリリース時はHTTPSが必須、とあちこちで見かけます
実際>>580の仕様の#security-considerationsをみるとHTTPSが必須とあり、
* 中間者攻撃に対して（HTTPと比べ）まだマシ
* HTTPSの利用を促進するため
* 既存の有力サービスはすでにHTTPSを利用している
というような内容が理由になっています

・挙げられている理由はどれもServiceWorker特有の問題ではないようにも見えますが、
　もしHTTP上での利用が可能で実際HTTPで運用した場合、ServiceWorker特有の危険性としてはどんなものがあるのでしょうか
・逆にHTTPSを利用する場合、エンドユーザ視点では、
　ServiceWorkerを受け入れ利用することにどんな危険性/デメリットがあるでしょうか？

587 = :

どんなってもう答え自分で言ってるじゃん。
中間者攻撃で任意のネットワークプロキシが差し込まれると考えたら大変なことでしょ。
ユーザー側の一番の問題はブラウザを閉じても沢山のSWが常駐することによるリソース食い。
Chromeが一時拡張たくさん入れると重いと言われてたのと同じことが起き得る。
但し、最近の拡張は必要なときだけ起きることができるようになったように、
その反省を活かして仕様を作っていかないといけない。

588 = :

まだいるよこのカス

589 = :

スレチにもほどがある
池沼は帰れよ

590 = :

中間者攻撃が当該サイトにだけ通用するローカルなプロキシに及ぶと
具体的に一体なにがどう大変なのか説明しないと説得力ないぞ

591 = :

>>586
何か組み合わせた攻撃があった時、その特性から言って発見が遅れるだろう
そういう点で改竄に強いsslと違い、HTTPのがリスクは高いかな

特有の脆弱性なあ…別に特権付いたわけでもなし、杞憂だと思うが

592 = :

リソース食いもよく分からんね
むしろ減るだろ

593 = :

今って非同期通信しようと思ったらfetch apiをつかうのがデファクトでしょうか？
いちおうbabelを使っているのでES2015以降の流儀に合わせたいのですが、
実は良くないとか、他にもいいのがあるとかあったら教えていただきたいです。

594 = :

>>593
Fetch APIはそのAPIの仕様で非同期通信が含まれるだけであって
非同期通信したいときに使うものじゃないよ。

非同期に使われる技術はPromise一択、個人的には標準のPromiseよりも
Bluebirdの方が便利な機能があるので好き
jQueryも3.0で標準のPromiseに準拠するしね。

Promiseは単なるJavaScriptライブラリで実装可能なのでちょっと前のブラウザでも動く

そしてES6の機能でPromiseベースのモジュールを便利に使えるのがGeneratorだ。

そしてES7の機能でPromiseベースのモジュールを更に便利に使えるのがasync / awaitだ

595 = :

ついに自演はじめたよ

596 = :

俺はID見えるからな。

597 = :

元からIDあるけど
???って出てるやつは時代遅れなだけ

598 = :

昨日から気持ち悪い奴がいるな

599 = :

また自演か

600 = :

>>590
公共のネットワークで仕込まれたらそこを離れても改ざんされ続ける
キャッシュポイズニングの中でもひどい例
閲覧者に発覚しない程度に広告だけ差し替えるとか、いろんな試みが柔軟に行える

>>592
主にメモリリソースのことを言ってる